How can I avoid the dreaded "cannot compute suffix of object files"?

Dr. David Kirkby david.kirkby@onetel.net
Sun Feb 14 16:08:00 GMT 2010


Andrew Haley wrote:
> On 02/14/2010 11:35 AM, David Kirkby wrote:
>> On 11 February 2010 18:49, Andrew Haley <aph@redhat.com> wrote:
>>
>>> LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib
>>>
>>> is wrong, BTW.  You want the -R arg to point to your mpfr's lib as well.
>>>
>>> (This is the -rpath I talked about.  We tend to avoid it like the plague,
>>> as it means you can't move libraries.)
>> I'd specifically put mpir and mpfr libraries in the same place I
>> intended put gcc, so that was not the issue. The problem was I'd put
>> gcc-4.3.4 in the LD_OPTIONS, when it should have been gcc-4.4.3 - I'd
>> transposed the last two digits.
>>
>> To my logic, LD_LIBRARY_PATH should be used when one moves binaries.
>> That is one of its uses. For other reasons tasks is is a disaster. For
>> example, it can't be used if creating binaries with the setuid or
>> setgid bit set. (Well, it can be used, but it will be ignored!)
> 
> Quite right too.  I hope there are not going to be very many of those
> in non-system packages!
> 
>> See the link below "Why LD_LIBRARY_PATH is bad" by David Barr.
>>
>> http://xahlee.org/UnixResource_dir/_/ldpath.html
> 
> Well, he's advocating -rpath.  It's an opinion he gets to have, but
> IMO -rpath is even more of a disaster than LD_LIBRARY_PATH.  The use
> of -rpath is, I suspect, related to the practice of putting packages
> under /opt in Solaris (and I think other SYSV based systems.)  We
> don't much do that in GNU/Linux because of the way that our package
> managers work: our libraries go into /lib, /usr/lib, or somesuch,
> binaries into /bin, and so on.  The system paths almost always do just
> fine, so there's no need for -rpath or for LD_LIBRARY_PATH.  However,
> if you are going to put each package, with its binaries and libraries,
> into its own directory under /opt, then you are probably going to need
> -rpath or something similar.  It's not great, of course, and you may
> end up with several versions of libfoo.so, each in a separate package
> under /opt.

I'm not convinced it should be necessary to have multiple copies of libfoo. I 
chose to put gmp and mpfr in the same directory as the gcc libs, in the hope it 
might just be easier for gcc to find them. But I doubt it was essential to do 
this if LD_OPTIONS is set correctly. If gcc can find the libs by use of 
LD_OPTIONS, then that should be enough.

I normally tend to use /usr/local personally, as /opt is a system directory, and 
I'd prefer to keep my own files separately. /opt, along with the rest of Solaris 
sits on a couple of 500 GB mirrored disks. /usr/local, and all user files sit on 
a couple of 2 TB mirrored disks. So even if Solaris gets totally screwed up, and 
a reinstall is quickest, I know my own files are on separate disks.

> There is no really perfect solution to this problem.  On my GNU/Linux
> system a couple of packages end up modifying /etc/ld.so.conf, and this
> is because the upstream maintainers of those packages have their own
> install tree that doesn't play well with the rest of the system, but
> there really are only a couple of packages like that.

That I assume needs root access to install, which IMHO is a bad thing.

> Andrew.
> 




More information about the Gcc-help mailing list