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

This is a discussion on 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. ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 57 of 57

Thread: gcc build fails "cannot compute suffix of object files"

  1. Re: gcc build fails "cannot compute suffix of object files"

    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

    ;-)

  2. Re: gcc build fails "cannot compute suffix of object files"

    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.


  3. Re: gcc build fails "cannot compute suffix of object files"

    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

  4. Re: gcc build fails "cannot compute suffix of object files"

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


  5. Re: gcc build fails "cannot compute suffix of object files"

    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.



  6. Re: gcc build fails "cannot compute suffix of object files"

    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.


  7. Re: gcc build fails "cannot compute suffix of object files"

    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.


  8. Re: gcc build fails "cannot compute suffix of object files"

    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)

  9. Re: gcc build fails "cannot compute suffix of object files"

    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.


  10. Re: gcc build fails "cannot compute suffix of object files"

    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.


  11. Re: gcc build fails "cannot compute suffix of object files"

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

  12. Re: gcc build fails "cannot compute suffix of object files"

    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.


  13. Re: gcc build fails "cannot compute suffix of object files"

    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.


  14. Re: gcc build fails "cannot compute suffix of object files"

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


  15. Re: gcc build fails "cannot compute suffix of object files"

    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.


  16. Re: gcc build fails "cannot compute suffix of object files"

    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


  17. Re: gcc build fails "cannot compute suffix of object files"

    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.



+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3