gcc build fails "cannot compute suffix of object files" - Solaris

Dave Uhring wrote:
> On Wed, 11 Jun 2008 13:14:01 -0400, Oscar del Rio wrote:
>
>> The linker is smart enough to pick the correct ELF class from the 32/64 bit
>> libraries. No more "wrong ELF class" errors.
>>
>> It took 14 minutes to build and install on a 8-core X4150!
>
> But did it pass the testsuite ;-)
>

my test suite was

% cat /tmp/test.c
#include

main()
{
printf ("Hello\n");
}

gcc test.c
gcc -m64 test.c

;-)

On Wed, 11 Jun 2008 14:04:41 -0400, Oscar del Rio wrote:
> Dave Uhring wrote:

>> But did it pass the testsuite ;-)

> gcc test.c
> gcc -m64 test.c
>
> ;-)

Now the real problem will come when trying to use it to build a c++
program that also requires something from /usr/sfw/lib. You have two
versions of libstdc++.so.

Dave Uhring wrote:

> Debian Etch, updated yesterday:
>
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 2008-06-10 03:09 /bin/sh -> bash

I'm not sure about stable Debian. Debian testing has bash by default,
but you can configure ash or dash as /bin/sh. Ubuntu, OTOH, has dash as
/bin/sh and you can configure bash if you want.

By "configure" I mean OS supported way of reconfiguration, not manual
symlink creation (which is, of course, always available).

> Seems like a few people are finally realizing that "striving to be POSIX
> compliant" is *not* "being POSIX compliant".

:-)

I think those few people realized that bash was too slow to run scripts
(boot scripts in particular), so they put something smaller and faster.

--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| dave@fly.srk.fer.hr

On Wed, 11 Jun 2008 20:30:31 +0000, Drazen Kacar wrote:
> Dave Uhring wrote:
>
>> Debian Etch, updated yesterday:
>>
>> $ ls -l /bin/sh
>> lrwxrwxrwx 1 root root 4 2008-06-10 03:09 /bin/sh -> bash
>
> I'm not sure about stable Debian. Debian testing has bash by default,
> but you can configure ash or dash as /bin/sh.

No thanks. I'm really not into chasing broken scripts.

> Ubuntu, OTOH, has dash as /bin/sh and you can configure bash if you want.

That would undoubtedly break some scripts too.

>> Seems like a few people are finally realizing that "striving to be POSIX
>> compliant" is *not* "being POSIX compliant".
>
> :-)
>
> I think those few people realized that bash was too slow to run scripts
> (boot scripts in particular), so they put something smaller and faster.

Whatever it takes. At the moment it seems that "striving" = "posturing".

On Wed, 11 Jun 2008 11:07:18 -0500, Dave Uhring wrote:

> I forgot to mention.... A few months back mplayer's configure script
> added something which pukes using #!/bin/sh. Change the she-bang to
> #!/usr/bin/bash. The penguins usually symlink /bin/bash to /bin/sh; after
> all, they're the same, aren't they?

Oscar found a configure hack for this. I just change the configure script
s/sh/bash/ as Ive run into it before.

AGT wrote:
> On Wed, 11 Jun 2008 11:07:18 -0500, Dave Uhring wrote:
>
>> I forgot to mention.... A few months back mplayer's configure script
>> added something which pukes using #!/bin/sh. Change the she-bang to
>> #!/usr/bin/bash. The penguins usually symlink /bin/bash to /bin/sh; after
>> all, they're the same, aren't they?
>
> Oscar found a configure hack for this. I just change the configure script
> s/sh/bash/ as Ive run into it before.
>
>


Better might be to fix the script so it does not need bash and try to
get the developers to use it.

The problem with accepting the GNUism is that GNU tools keep changing. I
can think of a couple of occasions recently where specific older
versions of gcc are needed to compile bits of software.

Sometimes I think the gnu tools are useful, but on others I think the
poor stability of them causes more problems than it solves.

On Thu, 12 Jun 2008 09:17:36 +0100, Dave wrote:
> AGT wrote:
>> On Wed, 11 Jun 2008 11:07:18 -0500, Dave Uhring wrote:

>>> The penguins usually symlink /bin/bash to /bin/sh; after
>>> all, they're the same, aren't they?
>>
>> Oscar found a configure hack for this. I just change the configure script
>> s/sh/bash/ as Ive run into it before.

Indeed. I have been doing this for some time also.

> Better might be to fix the script so it does not need bash and try to
> get the developers to use it.

Lots of luck with that. My "question" was not entirely rhetorical as far
as many people are concerned. OTOH, I have not tried to use the POSIX
Bourne shell in the script yet. Remember, Solaris /bin/sh is not exactly
a portable shell.

> The problem with accepting the GNUism is that GNU tools keep changing.

s/changing/improving/ ;->

> I can think of a couple of occasions recently where specific older
> versions of gcc are needed to compile bits of software.

That's the price to pay for using legacy software.

> Sometimes I think the gnu tools are useful, but on others I think the
> poor stability of them causes more problems than it solves.

One can't drive a Phillips head screw with a Torx driver either. We just
have to use the tools which are available - or construct our own.

Dave Uhring wrote:
> Now the real problem will come when trying to use it to build a c++
> program that also requires something from /usr/sfw/lib. You have two
> versions of libstdc++.so.

That has long been the case with locally installed gcc (/usr/local or
/opt/local) vs blastwave's (/opt/csw) and Sun's (/usr/sfw). So far I
haven't seen many problems (that can't be fixed with LD flags).

I tend to use Sun's (Studio and gcc), leaving the other versions for the
odd packages that require specific compilers (I still have gcc 2.x
somewhere)

On Thu, 12 Jun 2008 08:21:48 -0400, Oscar del Rio wrote:

> Dave Uhring wrote:
>> Now the real problem will come when trying to use it to build a c++
>> program that also requires something from /usr/sfw/lib. You have two
>> versions of libstdc++.so.
>
> That has long been the case with locally installed gcc (/usr/local or
> /opt/local) vs blastwave's (/opt/csw) and Sun's (/usr/sfw). So far I
> haven't seen many problems (that can't be fixed with LD flags).

If your program needs to link with libssl.so, e.g., there is some
difficulty in avoiding the libstdc++.so that is in /usr/sfw/lib.

> I tend to use Sun's (Studio and gcc), leaving the other versions for the
> odd packages that require specific compilers (I still have gcc 2.x
> somewhere)

Those are the only two that I really need. I used to need gcc-2 to build
the smpeg lib and plaympeg but mplayer is a better app anyway, and it's
being maintained.

On Thu, 12 Jun 2008 09:17:36 +0100, Dave wrote:

> AGT wrote:
>> On Wed, 11 Jun 2008 11:07:18 -0500, Dave Uhring wrote:
>>
>>> I forgot to mention.... A few months back mplayer's configure script
>>> added something which pukes using #!/bin/sh. Change the she-bang to
>>> #!/usr/bin/bash. The penguins usually symlink /bin/bash to /bin/sh; after
>>> all, they're the same, aren't they?
>>
>> Oscar found a configure hack for this. I just change the configure script
>> s/sh/bash/ as Ive run into it before.
> Better might be to fix the script so it does not need bash and try to
> get the developers to use it.

Yeah right. Talking sense to Penguinites. Pull the other one mate : >

> The problem with accepting the GNUism is that GNU tools keep changing. I
> can think of a couple of occasions recently where specific older
> versions of gcc are needed to compile bits of software.

Been down that road YEARS ago. Nothing new. Esp. when it comes to c++
Talk about mangleing

> Sometimes I think the gnu tools are useful, but on others I think the
> poor stability of them causes more problems than it solves.

Stability issues I dont encounter much.
This latest gcc though is a candidate for BAD software engineering where
running a 64 bit make test results in ~99% failure but gcc -m64
compiles 64 bit code like openssl just fine even at -O4
That was mpfr I think...

Sometimes gtools are needed to compile GNU stuff. The alternative is
to fix the code and submit the changes to the 'developers' who
usually ignore you : > That means every week or so when a new
"improved" version comes out you go through the same thing again.
Maybe you get ignored because the code changes so MUCH that
submitting diffs are pointless : /

Or just use Blastwave and be done with it.

AGT wrote:
> This latest gcc though is a candidate for BAD software engineering where
> running a 64 bit make test results in ~99% failure but gcc -m64
> compiles 64 bit code like openssl just fine even at -O4
> That was mpfr I think...

The test failures might have to do with GMP having the ABI hardcoded in gmp.h.

#define __GMP_BITS_PER_MP_LIMB 32
#define GMP_LIMB_BITS 32

but a single gmp.h is installed in $prefix/include when you build
both ABI=32 and ABI=64 versions (whichever you install last).

AGT wrote:

>> Sometimes I think the gnu tools are useful, but on others I think the
>> poor stability of them causes more problems than it solves.
>
> Stability issues I dont encounter much.
> This latest gcc though is a candidate for BAD software engineering where
> running a 64 bit make test results in ~99% failure but gcc -m64
> compiles 64 bit code like openssl just fine even at -O4
> That was mpfr I think...
>

I should have rerphrased that. By "stabiltity" I mean the interfaces
keep changing - not as in crashing. You can't rely on something be the
same from one release to the next, which is why you need to keep several
versions of gcc around to compile different bits of code.

I'm trying to help out with Sage

http://www.sagemath.org/

One of the components of that will not compile on gcc 4.3 on Solaris
(will on other OS's). Other bits will not compile on 2.x or 3.x.


> Sometimes gtools are needed to compile GNU stuff. The alternative is
> to fix the code and submit the changes to the 'developers' who
> usually ignore you : > That means every week or so when a new
> "improved" version comes out you go through the same thing again.
> Maybe you get ignored because the code changes so MUCH that
> submitting diffs are pointless : /

This is my point. gcc developers in particular seem to keep adding code,
and features, but don't seem too keen to fix the underlying problems.

It would be much better if they concentrated their efforts in ensuring
gcc compiled with any compiler produced in the last 10-15 years. Ensure
it compiles with the native compilers of lots of operating systems.


> Or just use Blastwave and be done with it.


But code gets more and more difficult to maintain with the GNUisms one
tends to see. I noticed Blastwave have not updated gcc since 4.0.2.

On Thu, 12 Jun 2008 08:05:04 -0500, Dave Uhring wrote:

> On Thu, 12 Jun 2008 08:21:48 -0400, Oscar del Rio wrote:
>
>> Dave Uhring wrote:
>>> Now the real problem will come when trying to use it to build a c++
>>> program that also requires something from /usr/sfw/lib. You have two
>>> versions of libstdc++.so.
>> That has long been the case with locally installed gcc (/usr/local or
>> /opt/local) vs blastwave's (/opt/csw) and Sun's (/usr/sfw). So far I
>> haven't seen many problems (that can't be fixed with LD flags).
> If your program needs to link with libssl.so, e.g., there is some
> difficulty in avoiding the libstdc++.so that is in /usr/sfw/lib.

It can be done. Just write a function that sets the env up so that
/usr/sfw /opt/csw whatever you dont want is never seen by "configure"
etc. When done, exec your shell to restore normalcy.

On Thu, 12 Jun 2008 12:31:23 -0400, Oscar del Rio wrote:

> AGT wrote:
>> This latest gcc though is a candidate for BAD software engineering where
>> running a 64 bit make test results in ~99% failure but gcc -m64
>> compiles 64 bit code like openssl just fine even at -O4
>> That was mpfr I think...
> The test failures might have to do with GMP having the ABI hardcoded in gmp.h.
> #define __GMP_BITS_PER_MP_LIMB 32
> #define GMP_LIMB_BITS 32
> but a single gmp.h is installed in $prefix/include when you build
> both ABI=32 and ABI=64 versions (whichever you install last).

O my
A well placed #if defined() #else would fix that. To think this is a math
project : >

On Thu, 12 Jun 2008 16:09:50 -0700, AGT wrote:
> On Thu, 12 Jun 2008 08:05:04 -0500, Dave Uhring wrote:

>> If your program needs to link with libssl.so, e.g., there is some
>> difficulty in avoiding the libstdc++.so that is in /usr/sfw/lib.
>
> It can be done. Just write a function that sets the env up so that
> /usr/sfw /opt/csw whatever you dont want is never seen by "configure"
> etc. When done, exec your shell to restore normalcy.

Errrm, libssl.so still needs to be found, if not by the configure script
then by /usr/ccs/bin/ld at link time and ld is also going to be finding
/usr/sfw/lib/libstdc++.so, which will conflict grandly with
/opt/local/lib/libstdc++.so.

It might be possible - I had not tried it - to specifically link
/usr/sfw/lib/libssl.so rather than having -L/usr/sfw/lib -lssl in the
Makefile. If -R/usr/sfw/lib is still passed to ld then ld.so.1 "should"
find libssl.so at run time.

On Thu, 12 Jun 2008 18:33:24 -0500, Dave Uhring wrote:

> On Thu, 12 Jun 2008 16:09:50 -0700, AGT wrote:
>> On Thu, 12 Jun 2008 08:05:04 -0500, Dave Uhring wrote:
>>> If your program needs to link with libssl.so, e.g., there is some
>>> difficulty in avoiding the libstdc++.so that is in /usr/sfw/lib.
>> It can be done. Just write a function that sets the env up so that
>> /usr/sfw /opt/csw whatever you dont want is never seen by "configure"
>> etc. When done, exec your shell to restore normalcy.
> Errrm, libssl.so still needs to be found, if not by the configure script
> then by /usr/ccs/bin/ld at link time and ld is also going to be finding
> /usr/sfw/lib/libstdc++.so, which will conflict grandly with
> /opt/local/lib/libstdc++.so.
>
> It might be possible - I had not tried it - to specifically link
> /usr/sfw/lib/libssl.so rather than having -L/usr/sfw/lib -lssl in the
> Makefile. If -R/usr/sfw/lib is still passed to ld then ld.so.1 "should"
> find libssl.so at run time.

Just a sec - this has become a rather long thread so I had to back
several posts for context. It starts:

"Now the real problem will come when trying to use it to build a c++
program that also requires something from /usr/sfw/lib. You have two
versions of libstdc++.so."

Not sure what "it" is - perhaps that matters

find . -name "libstdc++.so" -print
../libstdc++.so
../sparcv9/libstdc++.so

So we have a 64 bit version and a 32 bit version
I dont see how not setting up a special env wont handle this ; >

If you mean:
ldd ./libstdc++.so
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
and you dont want that then I'd need to know what "it" is : >

Actually I find I ned to know what "it" quite a lot... : /
never mind
It requires a certain amount of 'future think' for configure
for most situations is all.

Some manual intervention after install may be required if you are like me
a bit lazy and dont feel like groping through a configure
env for some special install setting that may or may not exist - after all
there must be 1000's of different "configures" out there few of which
behave identically. Even in the same source suite.

A worst case scenario would be to have to set up an isaexec'd binary after
install.

Then again I may have COMPLETELY missed your point altogether!

Perhaps a new Subject and thread is in order here

On Fri, 13 Jun 2008 07:51:55 -0700, AGT wrote:

> "Now the real problem will come when trying to use it to build a c++
> program that also requires something from /usr/sfw/lib. You have two
> versions of libstdc++.so."
>
> Not sure what "it" is - perhaps that matters

"It" is the new gcc-4 compiler with its own libstdc++.so which is in
/opt/local/lib.

The program source being compiled requires libssl.so which is in
/usr/sfw/lib, also the location of libstdc++.so for gcc-3.

So /usr/ccs/bin/ld must prepare an ELF header which searches both
/opt/local/lib to find the correct libstdc++.so and /usr/sfw/lib to find
libssl.so. But ld will also find a libstdc++.so in /usr/sfw/lib and it
will bitch loudly about conflicting libraries. The compile fails at this
point.

> Some manual intervention after install may be required if you are like
> me a bit lazy and dont feel like groping through a configure env for
> some special install setting that may or may not exist - after all there
> must be 1000's of different "configures" out there few of which behave
> identically. Even in the same source suite.

There will be no install in the first place because the linking part of
the compile will fail due to the conflicting libstdc++.so libraries,
assuming that your Makefile contains the usual -L/usr/sfw/lib -lssl.

I've been there and done that and that is the reason that the only GNU
compiler I have on my systems is the one shipped by Sun.