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 ; AGT wrote: > Eventually it did so that worked. > I just built mplayer from a source snapshot in 32 bit. > 64 Im not so sure yet What options did you use? Can you post the top of config.log, ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 57

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

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

    AGT wrote:

    > Eventually it did so that worked.
    > I just built mplayer from a source snapshot in 32 bit.
    > 64 Im not so sure yet


    What options did you use? Can you post the top of config.log, which I
    think has them.


    >> It's hard to believe they would release a version of gcc without testing
    >> it properly on at the very least Solaris 10 on x86 and SPARC.

    >
    > That would require skill sets they dont seem to possess



    It really is poor. I've looked at the 'wireshark' developers list, as I
    thought I might have some work building some addons to wireshark. They
    have a totally different attitude. They use a 'buildbot'

    http://buildbot.net/trac

    which automatically compiles the wireshark sources on multiple
    platforms, and sends an email to developers if there is a problem. It
    list the possible guilty parties - i.e. those that have committed code
    since it last built ok.

    A typical message from the buildbot is:

    http://www.wireshark.org/lists/wires.../msg00028.html

    The developers immediately know it has failed to compile on OSX-10.5-x86
    and who is to blame.

    I'm not a wireshark developer, but they seem to be pretty keen on
    quality to me.

    >> I suspect the problem in the usual one - people don't make the effort to
    >> check that code builds properly on other platforms.

    >
    > There is only Penguin OS...
    > There is only Intel...
    > Gee sounds almost like Mr. Bill all over again huh?


    It's certainly not Wolfram Research with Mathematica on Solaris. They
    support SPARC processors, as well as AMD processors on Solaris x86 but
    not Intel processors on Solaris x86. I can't understand the logic of
    supporting AMD, but not Intel on Solaris x86.

    http://www.wolfram.com/products/mathematica/platforms/

    > Seem to recall there is an initiative to test your software/equipment on
    > Sun equipment. i dont write software so i never followed up.
    >
    > Fact is there is no excuse as you can get a SPARC box for next to nothing
    > on eBay for a test platform and theres VMWare or Virtual Box for FeeCees.


    I think the problem is people are not going to bother unless it is easy.
    When I wanted portable code, I personally bought

    * IBM server running AIX
    * SGI Octane running IRIX
    * HP workstation running HP-UX
    * Dec Alpha for which I put tru64 on it.
    * Sun SPARC
    * Sun Intel

    and made some effort to get others to test on other platforms. I also
    used a Cray for which there is public access.

    gcc developers have a very different attitude.



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

    On Mon, 09 Jun 2008 21:54:56 -0500, Dave Uhring wrote:
    > On Mon, 09 Jun 2008 18:25:38 -0700, AGT wrote:
    >> On Mon, 09 Jun 2008 15:42:20 -0500, Dave Uhring wrote:
    >> Anyway I guess my point is that you have to be prepared for all kinds of
    >> nonsense with this "configure" rubbish. But anyone working with GNU stuff
    >> on Solaris knows this already.

    > Normally the GNU autoconf generated configure scripts are pretty well
    > behaved and produce usable Makefiles and config.h. Version 4 of gcc is
    > anything but well behaved.


    WHICH autoconf? : > Lest we forget that 'developers' quite often
    make that a prerequisite as well : < Anyway there is no such thing as
    normal with this stuff. But sometimes we get lucky and configure 'just
    works'

    >> Hours have passed and Im now at a c++ 32 bit shared build stage.. So
    >> setting LDFLAGS turned the trick it seems. So far.

    >
    > You may yet find a problem in building libstdc++ when the build produces
    > 64 bit objects but expects to link them with 32 bit objects.


    Didnt happen : >
    I could try compiling openssh in 64 bit to see if 64 bit
    works at ALL. Im not terribly hopeful. But I suppose
    I should take a run at building an x86 version before I go there..

    > I did try building gcc-4 only as an exercise. The GNU compiler which
    > ships with Solaris is quite adequate for building even the latest version
    > of the qt library, KDE and everything else which I wanted available and
    > which would not build with Studio12. qt will build with Studio12 but KDE
    > pukes with Sun's compiler.


    Agreed - sometimes the code is so BAD only gcc will compile it : >


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

    On Tue, 10 Jun 2008 08:03:42 +0100, Dave wrote:

    > AGT wrote:
    >
    >> Eventually it did so that worked.
    >> I just built mplayer from a source snapshot in 32 bit.
    >> 64 Im not so sure yet

    >
    > What options did you use? Can you post the top of config.log, which I
    > think has them.


    Due to my usage of 'env' I dont think they'll all show up
    And I built on SPARC but I'd like to believe that doesnt matter.
    HA! The options were entirely generic

    configure --prefix=/opt/gcc --enable-multilib --enable-languages and two
    options for the gmp and other prerequitiste lib as suggested by configure

    env included LD_RUN_PATH=/usr/lib:/opt/gcc/lib:/opt/gcc/lib/sparcv9
    LDFLAGS="-L -R -L -R" (where the gmp libs are) INSTALL=/usr/ucb/install
    MAKE=gmake

    But thats not enough. At least one configure file will fail because
    its really a bash shell script. So you have to change the top line from
    /bin/sh to /bin/bash [ Yet Another Penguinism ]. Some Makefiles
    have to be repaired due to hard coded install commands and usage
    of GNU grep instead of Sun grep. On and on. Thats why it took all DAY

    >>> It's hard to believe they would release a version of gcc without
    >>> testing
    >>> it properly on at the very least Solaris 10 on x86 and SPARC.

    >> That would require skill sets they dont seem to possess

    > It really is poor. I've looked at the 'wireshark' developers list, as I
    > thought I might have some work building some addons to wireshark. They
    > have a totally different attitude. They use a 'buildbot'
    > http://buildbot.net/trac
    > which automatically compiles the wireshark sources on multiple
    > platforms, and sends an email to developers if there is a problem. It
    > list the possible guilty parties - i.e. those that have committed code
    > since it last built ok.


    O that would never fly on the South Pole : >

    > I'm not a wireshark developer, but they seem to be pretty keen on
    > quality to me.


    Its a blessing that program.

    >>> I suspect the problem in the usual one - people don't make the effort
    >>> to check that code builds properly on other platforms.

    >> There is only Penguin OS...
    >> There is only Intel...
    >> Gee sounds almost like Mr. Bill all over again huh?

    >
    > It's certainly not Wolfram Research with Mathematica on Solaris. They
    > support SPARC processors, as well as AMD processors on Solaris x86 but
    > not Intel processors on Solaris x86. I can't understand the logic of
    > supporting AMD, but not Intel on Solaris x86.
    >
    > http://www.wolfram.com/products/mathematica/platforms/
    >
    >> Seem to recall there is an initiative to test your software/equipment
    >> on Sun equipment. i dont write software so i never followed up.
    >>
    >> Fact is there is no excuse as you can get a SPARC box for next to
    >> nothing on eBay for a test platform and theres VMWare or Virtual Box
    >> for FeeCees.

    >
    > I think the problem is people are not going to bother unless it is easy.


    Doesnt give a whole lot of confidence in these people or their 'product'
    does it?

    > When I wanted portable code, I personally bought
    > * IBM server running AIX
    > * SGI Octane running IRIX
    > * HP workstation running HP-UX
    > * Dec Alpha for which I put tru64 on it. * Sun SPARC * Sun Intel
    > and made some effort to get others to test on other platforms. I also
    > used a Cray for which there is public access.


    Thats going a bit far for a "small" project but well done I say.

    > gcc developers have a very different attitude.


    Thank goodness we can usually use Studio 11 or 12 now.
    Im QUITE looking forward to the delivery of my Try & Buy
    5120 with its 32 threads and T2 processor : >
    Fun with dmake? Very likely!



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

    On Tue, 10 Jun 2008 08:41:13 -0700, AGT wrote:
    > On Mon, 09 Jun 2008 21:54:56 -0500, Dave Uhring wrote:


    >> I did try building gcc-4 only as an exercise. The GNU compiler which
    >> ships with Solaris is quite adequate for building even the latest version
    >> of the qt library, KDE and everything else which I wanted available and
    >> which would not build with Studio12. qt will build with Studio12 but KDE
    >> pukes with Sun's compiler.

    >
    > Agreed - sometimes the code is so BAD only gcc will compile it : >


    Exactly! Are there any CFLAGS for Studio12 which will cause the compiler
    to overlook those errors as gcc does?


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

    Dave wrote:

    > Since you seem to be getting further than me, as you are running for
    > hours and mine is bombing out after only 5 minutes, what are use using?


    It built without errors in Nevada b90.

    SunOS 5.11 snv_90 i86pc i386 i86pc Solaris

    First I installed gmp and mpfr, both 32 and 64-bit versions
    (in /opt/local/lib and /opt/local/lib/64) which took a few tries.

    Env:

    PATH=/usr/gnu/bin:/usr/sfw/bin:/usr/bin:/usr/sbin:/usr/ccs/bin

    (I put "GNU" stuff first in the PATH just in case - not sure if
    it makes any difference in the build)

    CPPFLAGS=-I/opt/local/include
    CONFIG_SHELL=/bin/bash
    LDFLAGS=-L/opt/local/lib -R/opt/local/lib
    LD_OPTIONS=-L/opt/local/lib -R/opt/local/lib

    .../configure --prefix=/opt/local --with-local-prefix=/opt/local
    --enable-languages=c,c++,fortran --with-gmp=/opt/local --with-mpfr=/opt/local
    --with-gnu-as --with-as=/usr/sfw/bin/gas

    gmake -j 8 && gmake install (using 8 cores, it builds in a few minutes)

    First I had to install gmp and mpfr, both 32 and 64-bit versions
    (in /opt/local/lib and /opt/local/lib/64)

    % /opt/local/bin/gcc -v
    Using built-in specs.
    Target: i386-pc-solaris2.11
    Configured with: ../configure --prefix=/opt/local --with-local-prefix=/opt/local
    --enable-languages=c,c++,fortran --with-gmp=/opt/local --with-mpfr=/opt/local
    --with-gnu-as --with-as=/usr/sfw/bin/gas
    Thread model: posix
    gcc version 4.3.1 (GCC)



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

    I wrote:

    > CPPFLAGS=-I/opt/local/include
    > CONFIG_SHELL=/bin/bash
    > LDFLAGS=-L/opt/local/lib -R/opt/local/lib
    > LD_OPTIONS=-L/opt/local/lib -R/opt/local/lib
    >
    > ../configure --prefix=/opt/local --with-local-prefix=/opt/local
    > --enable-languages=c,c++,fortran --with-gmp=/opt/local
    > --with-mpfr=/opt/local --with-gnu-as --with-as=/usr/sfw/bin/gas
    >
    > gmake -j 8 && gmake install (using 8 cores, it builds in a few minutes)


    problems with the 64-bit libs:

    ldd /opt/local/lib/64/libstdc++.so
    libgcc_s.so.1 => /opt/local/lib/libgcc_s.so.1 - wrong ELF class: ELFCLASS32

    same for the 64-bit versions of libssp.so, libgomp.so, libgfortran.so

    What's the correct way to build gcc so that 32-bit libs are
    searched in /opt/local/lib and 64-bit libs in /opt/local/lib/64?

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

    On Tue, 10 Jun 2008 17:26:23 -0400, Oscar del Rio wrote:

    > What's the correct way to build gcc so that 32-bit libs are
    > searched in /opt/local/lib and 64-bit libs in /opt/local/lib/64?


    Specify Sun's ld?

    The gcc shipped with b_90 has this:

    --with-ld=/usr/ccs/bin/ld --without-gnu-ld


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

    Oscar del Rio wrote:
    > Dave wrote:
    >
    >> Since you seem to be getting further than me, as you are running for
    >> hours and mine is bombing out after only 5 minutes, what are use using?

    >
    > It built without errors in Nevada b90.
    >
    > SunOS 5.11 snv_90 i86pc i386 i86pc Solaris
    >
    > First I installed gmp and mpfr, both 32 and 64-bit versions
    > (in /opt/local/lib and /opt/local/lib/64) which took a few tries.
    >
    > Env:
    >
    > PATH=/usr/gnu/bin:/usr/sfw/bin:/usr/bin:/usr/sbin:/usr/ccs/bin
    >
    > (I put "GNU" stuff first in the PATH just in case - not sure if
    > it makes any difference in the build)
    >
    > CPPFLAGS=-I/opt/local/include
    > CONFIG_SHELL=/bin/bash
    > LDFLAGS=-L/opt/local/lib -R/opt/local/lib
    > LD_OPTIONS=-L/opt/local/lib -R/opt/local/lib
    >
    > ../configure --prefix=/opt/local --with-local-prefix=/opt/local
    > --enable-languages=c,c++,fortran --with-gmp=/opt/local
    > --with-mpfr=/opt/local --with-gnu-as --with-as=/usr/sfw/bin/gas
    >
    > gmake -j 8 && gmake install (using 8 cores, it builds in a few minutes)
    >
    > First I had to install gmp and mpfr, both 32 and 64-bit versions
    > (in /opt/local/lib and /opt/local/lib/64)
    >
    > % /opt/local/bin/gcc -v
    > Using built-in specs.
    > Target: i386-pc-solaris2.11
    > Configured with: ../configure --prefix=/opt/local
    > --with-local-prefix=/opt/local --enable-languages=c,c++,fortran
    > --with-gmp=/opt/local --with-mpfr=/opt/local --with-gnu-as
    > --with-as=/usr/sfw/bin/gas
    > Thread model: posix
    > gcc version 4.3.1 (GCC)
    >
    >


    I was going to upgrade to b90 tommorow anyway, so I will wait until
    then. At which point i will try your suggestion. You have /usr/gnu as
    the first item in your path, but what is in there? I assume that
    whatever version of gcc you use is in there. What version of gcc are you
    compiling with? I've tired a 2.x, and 3.x and a 4.x, and got nowhere
    with any of them.

    I noticed you are using the GNU assembler. From what I understood from
    others, it was better to use the Sun linker and assembler - that is the
    way Blastwave builds it, and I think Sunfreeware too.


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

    On Tue, 10 Jun 2008 11:20:54 -0500, Dave Uhring wrote:

    > On Tue, 10 Jun 2008 08:41:13 -0700, AGT wrote:
    >> On Mon, 09 Jun 2008 21:54:56 -0500, Dave Uhring wrote:

    >
    >>> I did try building gcc-4 only as an exercise. The GNU compiler which
    >>> ships with Solaris is quite adequate for building even the latest version
    >>> of the qt library, KDE and everything else which I wanted available and
    >>> which would not build with Studio12. qt will build with Studio12 but KDE
    >>> pukes with Sun's compiler.


    KDE - talk about a work in "progress".. : <
    A pity as I rather like its look and feel compared to GNOME

    >> Agreed - sometimes the code is so BAD only gcc will compile it : >

    > Exactly! Are there any CFLAGS for Studio12 which will cause the compiler
    > to overlook those errors as gcc does?


    "those" errors? cc has an awful lot of switches, rather well documented
    I recall that 12 is more gcc tolerant or like in some respects but the
    details I do not recall. But I do not think mplayer for example will build
    w/o some extensive fixups.



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

    On Tue, 10 Jun 2008 16:52:36 -0700, AGT wrote:

    > KDE - talk about a work in "progress".. : <


    Nowhere nearly as much so as GNOME. Slackware Linux gave up on chasing
    all the varying GNOME requirements and dropped it from their distribution.
    It's easy to see why Sun doesn't chase the GNOME versions.

    > A pity as I rather like its look and feel compared to GNOME


    I've grown accustomed to GNOME. I had a bit of a problem getting into
    GNOME earlier today; the X config has changed since I replaced a 1280x1024
    display with one that does 1680x1050. I could log into "Failsafe" and
    started twm to fiddle with the X config. But I forgot to see if I could
    get KDE to start up.

    On the next login GNOME came back up without problems so I'll wait a bit
    to see if KDE will actually start.

    >> Exactly! Are there any CFLAGS for Studio12 which will cause the
    >> compiler to overlook those errors as gcc does?

    >
    > "those" errors? cc has an awful lot of switches, rather well documented
    > I recall that 12 is more gcc tolerant or like in some respects but the
    > details I do not recall. But I do not think mplayer for example will
    > build w/o some extensive fixups.


    mplayer is something of an oddball. Its configure script looks like one
    created with GNU autoconf but it's not. Only gmake can be used and forget
    about trying to use Studio12.


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

    I have a vague memory that gcc squirrels away the details of how it was
    built in one of its config files. If so, couldn't you take a look at the
    bundled version that comes with Solaris and use the same flags? Sorry if
    this has been discussed already, I've only skimmed the thread and not
    seen it.

    Bernie O.

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

    Dave Uhring wrote:
    > On Tue, 10 Jun 2008 17:26:23 -0400, Oscar del Rio wrote:
    >
    >> What's the correct way to build gcc so that 32-bit libs are
    >> searched in /opt/local/lib and 64-bit libs in /opt/local/lib/64?

    >
    > Specify Sun's ld?
    >
    > The gcc shipped with b_90 has this:
    >
    > --with-ld=/usr/ccs/bin/ld --without-gnu-ld
    >


    I checked that, with "gcc -v test.c". It is using Sun ld.

    ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1598

    The build would use gnu ld only if you specify --with-gnu-ld
    and the gnu path.

    I should RTFM about compiling 64-bit libraries.

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

    Dave wrote:
    > Oscar del Rio wrote:
    >> It built without errors in Nevada b90.
    >>
    >> SunOS 5.11 snv_90 i86pc i386 i86pc Solaris
    >> % /opt/local/bin/gcc -v
    >> Using built-in specs.
    >> Target: i386-pc-solaris2.11
    >> Configured with: ../configure --prefix=/opt/local
    >> --with-local-prefix=/opt/local --enable-languages=c,c++,fortran
    >> --with-gmp=/opt/local --with-mpfr=/opt/local --with-gnu-as
    >> --with-as=/usr/sfw/bin/gas
    >> Thread model: posix
    >> gcc version 4.3.1 (GCC)


    > I was going to upgrade to b90 tommorow anyway, so I will wait until
    > then. At which point i will try your suggestion. You have /usr/gnu as
    > the first item in your path, but what is in there? I assume that


    not much really

    /usr/gnu/bin:
    basename cat chgrp chmod chown chroot cksum cmp comm cp csplit cut date
    dd df diff diff3 dirname du echo egrep env expand expr factor false
    fgrep fmt fold grep groups head hostid hostname id join kill link ln
    logname ls m4 make mkdir mkfifo mknod mv nice nl nohup od paste patch
    pathchk pr printf pwd rm rmdir sdiff sh sleep sort split stty sum sync
    tail tar tee test touch tr true tsort tty uname unexpand uniq unlink
    uptime wc which who whoami yes

    > whatever version of gcc you use is in there. What version of gcc are you
    > compiling with? I've tired a 2.x, and 3.x and a 4.x, and got nowhere
    > with any of them.


    Sun's /usr/sfw/bin/gcc
    gcc version 3.4.3 (csl-sol210-3_4-20050802)

    > I noticed you are using the GNU assembler. From what I understood from
    > others, it was better to use the Sun linker and assembler - that is the
    > way Blastwave builds it, and I think Sunfreeware too.


    The build fails miserably without GNU assembler.
    Sun's gcc also uses "gas"

    > /usr/sfw/bin/gcc -v

    Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
    Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
    --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
    --with-ld=/usr/ccs/bin/ld --without-gnu-ld
    --enable-languages=c,c++,f77,objc --enable-shared

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

    On Tue, 10 Jun 2008 22:00:58 -0400, Oscar del Rio wrote:

    > Dave Uhring wrote:
    >> On Tue, 10 Jun 2008 17:26:23 -0400, Oscar del Rio wrote:
    >>
    >>> What's the correct way to build gcc so that 32-bit libs are
    >>> searched in /opt/local/lib and 64-bit libs in /opt/local/lib/64?

    >> Specify Sun's ld?
    >> The gcc shipped with b_90 has this:
    >> --with-ld=/usr/ccs/bin/ld --without-gnu-ld

    > I checked that, with "gcc -v test.c". It is using Sun ld.

    Interlesting. Im glad someone else has done this.
    I actually have to WORK the next 2 days : >
    > ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1598
    > The build would use gnu ld only if you specify --with-gnu-ld
    > and the gnu path.
    > I should RTFM about compiling 64-bit libraries.


    I sort of cheat in that I provide a list of directories to look
    in my LD_RUN_PATH [32 bit and 64 bit altogether]. For gcc multi-lib.
    For others I specify the sparcv9 dir when its not in /usr/lib. Suns ld
    accepts this and behaves. I never use gnu tools like gld or gas unless
    there is no other way to get something done.
    Most configures allow the install target dir to be specified to some
    degree of granularity. The studio compilers do a lot all by themselves.
    Only gcc has to be beaten into submission : > Its a rather special case
    though..

    I ran a make check on the 64 bit version of mpfr and got almost
    100% failure. So I was rather sceptical that openssl 64 bit
    would pass the make test but it did! Penguins blow it again : >


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

    On Tue, 10 Jun 2008 19:16:20 -0500, Dave Uhring wrote:

    > On Tue, 10 Jun 2008 16:52:36 -0700, AGT wrote:
    >> KDE - talk about a work in "progress".. : <

    > Nowhere nearly as much so as GNOME. Slackware Linux gave up on chasing
    > all the varying GNOME requirements and dropped it from their distribution.
    > It's easy to see why Sun doesn't chase the GNOME versions.


    At least they are trying harder. The KDE bunch seem quite flaky : <

    >> A pity as I rather like its look and feel compared to GNOME

    > I've grown accustomed to GNOME. I had a bit of a problem getting into
    > GNOME earlier today; the X config has changed since I replaced a 1280x1024
    > display with one that does 1680x1050. I could log into "Failsafe" and
    > started twm to fiddle with the X config. But I forgot to see if I could
    > get KDE to start up.
    > On the next login GNOME came back up without problems so I'll wait a bit
    > to see if KDE will actually start.


    good luck : >

    > mplayer is something of an oddball. Its configure script looks like one
    > created with GNU autoconf but it's not. Only gmake can be used and forget
    > about trying to use Studio12.


    I tried for a while but theres too many GNUisms in there. gmake is
    nearly always a given with this Penguinware stuff : < I usually
    just env MAKE=gmake


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

    On Wed, 11 Jun 2008 08:10:45 -0700, AGT wrote:
    > On Tue, 10 Jun 2008 19:16:20 -0500, Dave Uhring wrote:


    >> On the next login GNOME came back up without problems so I'll wait a bit
    >> to see if KDE will actually start.

    >
    > good luck : >


    konqueror and kpdf work well. Those were really the only apps which I
    wanted out of KDE.

    >> mplayer is something of an oddball. Its configure script looks like
    >> one created with GNU autoconf but it's not. Only gmake can be used and
    >> forget about trying to use Studio12.

    >
    > I tried for a while but theres too many GNUisms in there. gmake is
    > nearly always a given with this Penguinware stuff : < I usually just env
    > MAKE=gmake


    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?



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

    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?


    It's changing. For example Debian and Ubuntu have dash as /bin/sh these
    days. And yes, it "broke numerous shell scripts that relied upon
    bash-specific functionality." I suppose bashisms will be fixed in
    sort-of near future, thanks to popular distribution (Ubuntu) using
    something else for /bin/sh.

    For your gloating pleasure:

    http://en.wikipedia.org/wiki/Debian_Almquist_shell

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

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

    I wrote:
    >> CPPFLAGS=-I/opt/local/include
    >> CONFIG_SHELL=/bin/bash
    >> LDFLAGS=-L/opt/local/lib -R/opt/local/lib
    >> LD_OPTIONS=-L/opt/local/lib -R/opt/local/lib
    >>
    >> ../configure --prefix=/opt/local --with-local-prefix=/opt/local
    >> --enable-languages=c,c++,fortran --with-gmp=/opt/local
    >> --with-mpfr=/opt/local --with-gnu-as --with-as=/usr/sfw/bin/gas
    >>
    >> gmake -j 8 && gmake install (using 8 cores, it builds in a few minutes)

    >
    > problems with the 64-bit libs:
    >
    > ldd /opt/local/lib/64/libstdc++.so
    > libgcc_s.so.1 => /opt/local/lib/libgcc_s.so.1 - wrong ELF class:
    > ELFCLASS32
    >
    > same for the 64-bit versions of libssp.so, libgomp.so, libgfortran.so


    The following LD env variables fixed it

    LDFLAGS=-L/opt/local/lib -L/opt/local/lib/64 \
    -R/opt/local/lib:/opt/local/lib/64

    LD_OPTIONS=-L/opt/local/lib -L/opt/local/lib/64 \
    -R/opt/local/lib:/opt/local/lib/64

    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!

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

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


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

    On Wed, 11 Jun 2008 16:38:18 +0000, Drazen Kacar wrote:
    > 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?

    >
    > It's changing. For example Debian and Ubuntu have dash as /bin/sh these
    > days. And yes, it "broke numerous shell scripts that relied upon
    > bash-specific functionality." I suppose bashisms will be fixed in
    > sort-of near future, thanks to popular distribution (Ubuntu) using
    > something else for /bin/sh.


    Debian Etch, updated yesterday:

    $ ls -l /bin/sh
    lrwxrwxrwx 1 root root 4 2008-06-10 03:09 /bin/sh -> bash

    > For your gloating pleasure:
    >
    > http://en.wikipedia.org/wiki/Debian_Almquist_shell


    Seems like a few people are finally realizing that "striving to be POSIX
    compliant" is *not* "being POSIX compliant". Which is not to say that
    Solaris /bin/sh is compliant; it ain't.


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