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

Andrew Haley
Sun Feb 14 20:27:00 GMT 2010

On 02/14/2010 03:43 PM, Dr. David Kirkby wrote:
> Andrew Haley wrote:
>> On 02/14/2010 11:35 AM, David Kirkby wrote:
>>> On 11 February 2010 18:49, Andrew Haley <> 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.
>> 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, 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.

Sure, but if you've installed them locally for gcc, and no-one else
knows they're there, then there's no point them being shared
libraries.  All you get is slower access and more meory usage.

> 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/, 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.

Well, that's a matter of system policy, but if you have a shared
library then you might as well share it, and for the fairly obvious
security reasons you need root access to put it in a shared place.
I'm not aware that any other approach is possible, even in theory.


More information about the Gcc-help mailing list