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

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

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!

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?

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

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

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.

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.

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.

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.

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.

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

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

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

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?

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

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!

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

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.