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.

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

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.

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

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

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?

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.

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.

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

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