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

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

[Dr. David Kirkby]

I'm trying to build gcc 4.3.2 on a Sun Blade 1000 running Solaris 10 03/05 
(there are good reasons for wanting to use an older release of Solaris 10).

I've patched




1)  Patched the included gcc 3.4.3 with Sun's latest patch for gcc (123647-04)

2) Set environment variables.

$ export LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib
$ export LDFLAGS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib

3) GMP related things.

* export ABI=32
* Configured gmp with a prefix of /usr/local/gcc-4.3.2
* Built gmp
* Verified gmp passes all tests.
* Installed gmp to /usr/local/gcc-4.3.2


4) MPFR related things.

* Configured mpfr with a prefix of /usr/local/gcc-4.3.2
* Built mpfr
* Verified mpfr passes all tests.
* Installed mprf to /usr/local/gcc-4.3.2

5) GCC related things.

../gcc-4.4.3/configure  --prefix=/usr/local/gcc-4.4.3 
--with-mpfr-lib=/usr/local/gcc-4.4.3/lib 
--with-mpfr-include=/usr/local/gcc-4.4.3/include 
--with-build-time-tools=/usr/ccs/bin --with-gmp=/usr/local/gcc-4.4.3 
--enable-languages=c,c++,fortran --with-boot-ldflags="-R/usr/local/gcc-4.4.3/lib 
-L/usr/local/gcc-4.4.3/lib"


The sate 2 build fails with the error message "cannot compute suffix of object 
files", which is a result of it being unable to find the path to the mpfr 
library. This is despite the fact I've done everything I can think of to get gcc 
to look in /usr/local/gcc-4.4.3/lib for the mpfr libraries.

A Google on this message shows 901,000 hits. Adding 'gcc' into the search term 
finds this drops to 761,000, so I'm far from the only one to get this message.

The appropriate config.log

/patches/builds/build-gcc/sparc-sun-solaris2.10/libgcc/config.log

Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.3/configure --prefix=/usr/local/gcc-4.4.3 
--with-mpfr-lib=/usr/local/gcc-4.4.3/lib 
--with-mpfr-include=/usr/local/gcc-4.4.3/include --
with-build-time-tools=/usr/ccs/bin --with-gmp=/usr/local/gcc-4.4.3 
--enable-languages=c,c++,fortran --with-boot-ldflags='-R/usr/local/gcc-4.4.3/lib 
-L/usr/local/g
cc-4.4.3/lib'
Thread model: posix
gcc version 4.4.3 (GCC)
configure:2391: $? = 0
configure:2393: /patches/builds/build-gcc/./gcc/xgcc 
-B/patches/builds/build-gcc/./gcc/ 
-B/usr/local/gcc-4.4.3/sparc-sun-solaris2.10/bin/ -B/usr/local/gcc-4.4.3/s
parc-sun-solaris2.10/lib/ -isystem 
/usr/local/gcc-4.4.3/sparc-sun-solaris2.10/include -isystem 
/usr/local/gcc-4.4.3/sparc-sun-solaris2.10/sys-include -V </dev/nul
l >&5
xgcc: '-V' must come at the start of the command line
configure:2396: $? = 1
configure:2415: /patches/builds/build-gcc/./gcc/xgcc 
-B/patches/builds/build-gcc/./gcc/ 
-B/usr/local/gcc-4.4.3/sparc-sun-solaris2.10/bin/ -B/usr/local/gcc-4.4.3/s
parc-sun-solaris2.10/lib/ -isystem 
/usr/local/gcc-4.4.3/sparc-sun-solaris2.10/include -isystem 
/usr/local/gcc-4.4.3/sparc-sun-solaris2.10/sys-include -o conftest
-g -O2     conftest.c  >&5
ld.so.1: /patches/builds/build-gcc/gcc/cc1: fatal: libmpfr.so.1: open failed: No 
such file or directory
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

I know from experience adding the directory of the mpfr libraries to 
LD_LIBRARY_PATH, but it is generally reconised as poor practice to do this.

I reported this as a bug for 4.3.1 some time ago

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481

A suggestion was made to use

export LD_OPTIONS='-R/opt/csw/lib/$ISALIST'
(obviously I'd need to change the patch, as I'm not putting binaries under 
/opt/csw), but even that is not working for me.

Can anyone suggest how I can build gcc on Solaris so it does not need 
LD_LIBRARY_PATH set and compile-time and run-time?

What more can I possibly try?

Dave

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

[Andrew Haley]

On 02/11/2010 11:59 AM, Dr. David Kirkby wrote:

> 
> Can anyone suggest how I can build gcc on Solaris so it does not need
> LD_LIBRARY_PATH set and compile-time and run-time?
> 
> What more can I possibly try?

Build gmp and mpfr as *static* libraries.  Use the configure argument
--disable-shared for both.

Andrew.

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

[David Kirkby]

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.)
>
> Andrew.

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!)

See the link below "Why LD_LIBRARY_PATH is bad" by David Barr.

http://xahlee.org/UnixResource_dir/_/ldpath.html


Dave

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

[Andrew Haley]

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.

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.

Andrew.

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

[Dr. David Kirkby]

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

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

[Andrew Haley]

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

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

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.

Andrew.

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

[Dr. David Kirkby]

Dr. David Kirkby wrote:
> I'm trying to build gcc 4.3.2 on a Sun Blade 1000 running Solaris 10 
> 03/05 (there are good reasons for wanting to use an older release of 
> Solaris 10).

Sorry, that was supposed to be 4.4.3 (i.e. the latest version)

> I've patched
> 
> 
> 
> 
> 1)  Patched the included gcc 3.4.3 with Sun's latest patch for gcc 
> (123647-04)
> 
> 2) Set environment variables.
> 
> $ export LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib
> $ export LDFLAGS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib
> 
> 3) GMP related things.
> 
> * export ABI=32
> * Configured gmp with a prefix of /usr/local/gcc-4.3.2
> * Built gmp
> * Verified gmp passes all tests.
> * Installed gmp to /usr/local/gcc-4.3.2

Again, I meant to say to /usr/local/gcc-4.4.3

> 
> 4) MPFR related things.
> 
> * Configured mpfr with a prefix of /usr/local/gcc-4.3.2
> * Built mpfr
> * Verified mpfr passes all tests.
> * Installed mprf to /usr/local/gcc-4.3.2


Again, I meant to say to /usr/local/gcc-4.4.3

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

[Dennis Clarke]

> I'm trying to build gcc 4.3.2 on a Sun Blade 1000 running Solaris 10 03/05
> (there are good reasons for wanting to use an older release of Solaris
> 10).
>
> I've patched
>
>

David, I never use LD_LIBRARY_PATH on Solaris unless someone has a taser
pressed to my head. It is very bad practice.

Just try --with-gmp=/opt/csw --with-mpfr=/opt/csw or whereever you have
it. Do not put "lib" there.

Also, set your LD_OPTIONS correctly and use the Sun linker and you should
be okay.

-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

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

[Dr. David Kirkby]

Dennis Clarke wrote:

> David, I never use LD_LIBRARY_PATH on Solaris unless someone has a taser
> pressed to my head. It is very bad practice.

I can understand that.

> Just try --with-gmp=/opt/csw --with-mpfr=/opt/csw or whereever you have
> it. Do not put "lib" there.

I had tried that before, but it did not work.

> Also, set your LD_OPTIONS correctly and use the Sun linker and you should
> be okay.



This has just failed for me. I used a shell of /bin/bash, and also set

SHELL=/bin/bash

since some have said in the past that is necessary.

# env | grep LD

OLDPWD=/patches/builds/mpfr-2.4.2
LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib

# ../gcc-4.4.3/configure  --prefix=/usr/local/gcc-4.4.3 
--with-mpfr=/usr/local/gcc-4.4.3 --with-build-time-tools=/usr/ccs/bin 
--with-gmp=/usr/local/gcc-4.4.3  --enable-languages=c,c++,fortran

Can you tell me

1) How do you configure GMP - do you use a 32 or 64-bit ABI? What options are 
used to GMP's configure script.

2) Do you build GMP twice - one as a 32-bit ABI, and a second as a 64-bit ABI, 
and in the latter case putting the libraries in /opt/csw/lib/sparcv9 ?

2) How do you configure MPFR - what options are used to for MPRF's configure 
script? Again any specific issues about getting 32-bit libraries in /opt/csw/lib 
and 64-bit libraries in /opt/csw/lib/sparcv9 ?

3) What could be wrong with my setting of LD_OPTIONS of:

LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib

I've also tried just the -R bit, without the -L bit.

It's obvious to me you can do this, but I can't get the ****** thing to work for 
me!

dave

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

[Dr. David Kirkby]

Dr. David Kirkby wrote:

> 3) What could be wrong with my setting of LD_OPTIONS of:
> 
> LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib

Actually, I can see what is wrong. I transposed the last two digits - it should 
have been gcc-4.4.3, not 4.3.4

I know I made that mistake in a previous posting, but I thought it was a typo. 
This time I know I it was not. That could explain it.

I'd still like to know how you manage to get both 32 and 64-bit versions of gmp 
and mpfr.

Dave

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

[Dr. David Kirkby]

Dr. David Kirkby wrote:
> Dr. David Kirkby wrote:
> 
>> 3) What could be wrong with my setting of LD_OPTIONS of:
>>
>> LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib
> 
> Actually, I can see what is wrong. I transposed the last two digits - it 
> should have been gcc-4.4.3, not 4.3.4
> 
> I know I made that mistake in a previous posting, but I thought it was a 
> typo. This time I know I it was not. That could explain it.
> 
> I'd still like to know how you manage to get both 32 and 64-bit versions 
> of gmp and mpfr.
> 
> Dave
> 


OK, I set LD_OPTIONS to

-R/usr/local/gcc-4.4.3/lib -L/usr/local/gcc-4.4.3/lib

GCC 4.4.3 builds fine. There is no more of this "cannot compute suffix of object 
files" rubbish.

However, at runtime, gcc is failing to find gcc_lib.so, so not all binaries build.

fatal: libgcc_s.so.1: open failed: No such file or directory

Any ideas Dennis - or anyone else for that matter?

Dave

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

[Andrew Haley]

On 02/12/2010 12:36 PM, Dr. David Kirkby wrote:
> 
> OK, I set LD_OPTIONS to
> 
> -R/usr/local/gcc-4.4.3/lib -L/usr/local/gcc-4.4.3/lib
> 
> GCC 4.4.3 builds fine. There is no more of this "cannot compute suffix
> of object files" rubbish.
> 
> However, at runtime, gcc is failing to find gcc_lib.so, so not all
> binaries build.
> 
> fatal: libgcc_s.so.1: open failed: No such file or directory
> 
> Any ideas Dennis - or anyone else for that matter?

Probably LD_LIBRARY_PATH again?  You need to make sure that libgcc_s.so.1
is reachable.

When do you first see this failure?

Andrew.