Re: compile on Solaris 8 with gcc 3.2.2
* On 2003.10.31, in <20031101021550.GA12493@xxxxxxxx>,
* "Allister MacLeod" <amacleod@xxxxxxxx> wrote:
>
> I thought that the linker only included the .o files that were used.
Generally, yes. Solaris 8 should certainly be no exception.
> By the way, how come dynamic linking doesn't work? Is it safe to
> assume you attempted using shared libraries but the process failed?
I wonder this too. The dlopen fudgery is required to build static execs
on Solaris, but... why not just use shared? I can imagine reasons for
static build of some programs, but mutt doesn't strike me as a likely
candidate.
I wonder whether it's to do with libgcc. There's an apparently somewhat
new shift in gccthat I encountered just recently; they configure it by
default to compile applications with the the shared libgcc.so rather
than the static, as it used to be. (Inane and unappreciated, I say.) You
can disable this by editing your gcc specs file, and should if you can;
but if you can't it's probably possible to work around on the command
line by inserting libgcc.a as a direct build object. That is, you'd go
from something like this:
gcc -o foo foo.o bar.o -lfoobar
to this:
gcc -o foo foo.o bar.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/libgcc.a -lfoobar
The trouble here, and the reason this change in gcc graduates from
annoying to insidious, is that any shared libraries you build with
the new gcc, without some sort of tweak as above, can wind up with a
libgcc.so dependency. In this event you can't escape it as a dependency
even if you link to libgcc.a by name.
...
The reason all this is a problem at all is that for the first time,
running binaries built with gcc requires installation of a gcc runtime
environment on the machine running the program, even if that machine
never compiles code. This is no issue for Linux users and such, but
really annoying for those of us on (let's say) "traditional" Unixes, who
already have C runtimes, but need to install GNU's on top of our own
just to run apps compiled under recent gcc versions.
So, solutions:
1. just to downgrade gcc to something with rational behavior.
Unfortunately, I don't know when they made this change, exactly. My 2.95
and 3.1 both work right, but 3.2.1 does not.
2. rm .../gcc-lib/*/*/libgcc*.so* . This has the downside of breaking
anything that was compiled with the shared libgcc already, perhaps
including gcc itself.
3. Modify the specs file to force static libgcc.
Phew, that was a longer post than I expected.
--
-D. dgc@xxxxxxxxxxxx
University of Chicago > NSIT > VDN > ENSS > ENSA > You are here
. . . . . . .
always line up dots