Finding out if a lib has is compiled with -fPIC in it - Linux

This is a discussion on Finding out if a lib has is compiled with -fPIC in it - Linux ; Currently, if a library has been compiled without -fPIC, when trying to link it against an -fPIC object, the linker will complain with something like: /usr/bin/ld: /usr/local/lib64/libIlmImf.a(ImfChannelList.o): relocation R_X86_64_32S against Now, I was wondering if this problem could be detected ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Finding out if a lib has is compiled with -fPIC in it

  1. Finding out if a lib has is compiled with -fPIC in it


    Currently, if a library has been compiled without -fPIC, when trying
    to link it against an -fPIC object, the linker will complain with
    something like:

    /usr/bin/ld: /usr/local/lib64/libIlmImf.a(ImfChannelList.o):
    relocation R_X86_64_32S against

    Now, I was wondering if this problem could be detected before hand.
    Basically, I would like a tool like ldd that I could run routinely in
    my /usr/lib and /usr/local/lib directory to detect any static library
    that has been compiled incorrectly.

    Is there any such tool?

  2. Re: Finding out if a lib has is compiled with -fPIC in it

    gga writes:

    > Basically, I would like a tool like ldd that I could run routinely in
    > my /usr/lib and /usr/local/lib directory to detect any static library
    > that has been compiled incorrectly.


    It is perfectly correct to have archive libraries compiled without -fPIC.
    The error is in trying to link such a library into a shared object,
    not in compiling the archive library itself.

    Also, you aren't going to find many x86_64 libraries in /usr/lib
    (they usually go into /usr/lib64).

    > Is there any such tool?


    One isn't necessary (it's a one-liner):

    for i in /usr/lib/*.a /usr/local/lib/*.a; do
    objdump --reloc $i 2>/dev/null | grep R_X86_64_32S > /dev/null && echo $i;
    done

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: Finding out if a lib has is compiled with -fPIC in it

    Paul Pluzhnikov wrote:

    > Also, you aren't going to find many x86_64 libraries in
    > /usr/lib (they usually go into /usr/lib64).


    On a 64 bit system /lib is usually a symlink to /lib64
    and /usr/lib symlinks to /usr/lib64

    32 bit libraries usually reside in /lib32 and /usr/lib32 on those
    systems.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  4. Re: Finding out if a lib has is compiled with -fPIC in it

    Wolfgang Draxinger writes:

    > On a 64 bit system /lib is usually a symlink to /lib64
    > and /usr/lib symlinks to /usr/lib64


    This is false for all of x86_64 systems I have access to:

    SUSE LINUX 10.1 (X86-64)
    Fedora Core release 6 (Zod)
    Fedora release 7 (Moonshine)
    Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
    Red Hat Enterprise Linux ES release 4 (Nahant)
    Mandrakelinux release 10.2 (Limited Edition 2005) for x86_64

    Which distribution uses the scheme you described?

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  5. Re: Finding out if a lib has is compiled with -fPIC in it

    Paul Pluzhnikov writes:

    > Wolfgang Draxinger writes:
    >
    >> On a 64 bit system /lib is usually a symlink to /lib64
    >> and /usr/lib symlinks to /usr/lib64

    >
    > This is false for all of x86_64 systems I have access to:
    >
    > SUSE LINUX 10.1 (X86-64)
    > Fedora Core release 6 (Zod)
    > Fedora release 7 (Moonshine)
    > Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
    > Red Hat Enterprise Linux ES release 4 (Nahant)
    > Mandrakelinux release 10.2 (Limited Edition 2005) for x86_64
    >
    > Which distribution uses the scheme you described?


    Gentoo does.

    --
    Måns Rullgård
    mans@mansr.com

  6. Re: Finding out if a lib has is compiled with -fPIC in it

    On Dec 10, 4:21 am, gga wrote:

    > Currently, if a library has been compiled without -fPIC, when trying
    > to link it against an -fPIC object, the linker will complain with
    > something like:
    >
    > /usr/bin/ld: /usr/local/lib64/libIlmImf.a(ImfChannelList.o):
    > relocation R_X86_64_32S against


    Right, because that is illegal.

    > Now, I was wondering if this problem could be detected before hand.


    Before you knew you needed to do that? I don't see how.

    > Basically, I would like a tool like ldd that I could run routinely in
    > my /usr/lib and /usr/local/lib directory to detect any static library
    > that has been compiled incorrectly.


    What do you mean by "compiled incorrectly"? Compiling a static library
    without -fPIC is only incorrect if the static library is intended to
    be linked into dynamic libraries.

    > Is there any such tool?


    How would the tool know which static libraries, if any, were intended
    to be linked into dynamic libraries?

    DS

  7. Re: Finding out if a lib has is compiled with -fPIC in it

    On Dec 10, 12:07 pm, Paul Pluzhnikov
    wrote:

    >
    > Also, you aren't going to find many x86_64 libraries in /usr/lib
    > (they usually go into /usr/lib64).
    >


    Not on Debian systems. /usr/lib64 is symlink to /usr/lib. RedHat and
    others used to use the opposite, with /usr/lib pointing to /usr/lib32.
    I consider Debian correct as it keeps /usr/lib to the "natural" system
    architecture, while RH was more or less broken to keep back
    compatibility with old 32-bit systems, where /usr/lib was always
    assumed to be 32-bits. I think latest RH is now fixed to work like
    Debian.

    > One isn't necessary (it's a one-liner):
    >
    > for i in /usr/lib/*.a /usr/local/lib/*.a; do
    > objdump --reloc $i 2>/dev/null | grep R_X86_64_32S > /dev/null && echo $i;
    > done
    >


    Thanks. That's what I was looking for. Sigh, way too many static
    libs in my distro without -fPIC properly set.

    Now the big question is: why, other than perhaps size, would you ever
    want to have your .a libs in /usr/lib compiled without -fPIC?

  8. Re: Finding out if a lib has is compiled with -fPIC in it

    gga writes:

    > Now the big question is: why, other than perhaps size, would you ever
    > want to have your .a libs in /usr/lib compiled without -fPIC?


    Code compiled with -fPIC is slower and larger, so generally it's
    a bad idea to compile with -fPIC, unless you actually need to do so.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  9. Re: Finding out if a lib has is compiled with -fPIC in it

    On Dec 10, 9:52 pm, David Schwartz wrote:
    > On Dec 10, 4:21 am, gga wrote:
    >
    > What do you mean by "compiled incorrectly"? Compiling a static library
    > without -fPIC is only incorrect if the static library is intended to
    > be linked into dynamic libraries.
    >


    Which is how libs in /usr/lib should be shipped, right?
    Why is (my generic) distro assuming I'm not going to ever link any .a
    file into a dso? If it is in /usr/lib, my belief is that it should be
    as generic as possible.

    If I need speed or size, there's always tiny or from source distros
    like gentoo. Or I can always go and compile that specific lib as I
    need.

    Static libs are not used to run my os, they are used only to link
    against. I care about them actually linking and not me having to
    download 3 or 5 additional packages to try to figure how to compile
    them myself with the settings I need.
    Most autotools makefiles will also tend to compile against DSOs by
    default, not static libs, so static libs are mostly unused for most
    users.

    So the question remains, why is a generic distro like my Ubuntu box
    disting .a files without -fPIC?

    For example, I have /usr/lib/libz.a compiled without -fPIC on my
    distro. I think that's a serious mistake, as that's a *very* common
    lib.

  10. Re: Finding out if a lib has is compiled with -fPIC in it

    Måns Rullgård wrote:

    >> This is false for all of x86_64 systems I have access to:
    >>
    >> SUSE LINUX 10.1 (X86-64)
    >> Fedora Core release 6 (Zod)
    >> Fedora release 7 (Moonshine)
    >> Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
    >> Red Hat Enterprise Linux ES release 4 (Nahant)
    >> Mandrakelinux release 10.2 (Limited Edition 2005) for x86_64
    >>
    >> Which distribution uses the scheme you described?


    I don't take these distributions as an official standard.

    > Gentoo does.


    It's just logicial:
    In /lib and /usr/lib reside the "default" libraries, i.e. on a 64
    bit system that would be 64 bit libraries. Anything else should
    go to a specific location.

    That the 64 bit distributions you mentioned have 32 bit libraries
    in /lib and /usr/lib is probably due to legacy applications,
    that are still 32 bit and may be installed on a 64 bit system,
    their 32 bit libraries eventually clashing with already
    installed 64 bit ones.

    But this is more a problem of the package manager, as the dynamic
    linker will try to find a matching library in all the places on
    the system, that fits the application. So technically it doesn't
    matter where the libraries reside, as long they are in the
    library path.

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867


  11. Re: Finding out if a lib has is compiled with -fPIC in it

    On Dec 11, 1:14 am, gga wrote:

    > So the question remains, why is a generic distro like my Ubuntu box
    > disting .a files without -fPIC?


    Because the assumption is that you're either using static linking or
    shared libraries. If you're using shared libraries, there's libz.so.
    The .a file is for people who want to statically link.

    > For example, I have /usr/lib/libz.a compiled without -fPIC on my
    > distro. I think that's a serious mistake, as that's a *very* common
    > lib.


    You have a libz.so too, right?

    Why do you think you need/want something in-between static linking and
    dynamic linking?

    DS

+ Reply to Thread