Discussion:
Strange compiler/linker problem
Christoph Schulte Moenting
2004-07-14 23:08:52 UTC
Permalink
Hi,

I detected a strange problem and do not know if this is emx- or gcc-related.
When I try to compile the Jam sources (Jam is a kind of make tool), I get a
large list of undefined and multiply defined symbols (see failure.log). Now
when I add the gcc option -save-temps, I got no such errors, and the exe is
built (see success.log).

I could understand the difference if I had something like GCCOPT=-pipe in my
environment, but it is not set. I double-checked this by setting this variable,
and in that case you would also see the message "gcc: Warning: -pipe ignored
since -save-temps specified" which clearly is not shown in the failure log
(and I did call 'nmake > failure.log 2>&1').

Any hints on what goes wrong? Adding -save-temps to get something linked is
a very ugly hack :-)

Regards,
Christoph
S***@public.gmane.org
2004-07-15 08:57:02 UTC
Permalink
Post by Christoph Schulte Moenting
Any hints on what goes wrong? Adding -save-temps to get
something linked is
a very ugly hack :-)
Looks like an EMX bug to me:
Looking at the temporary file names in your failure log, I'd suppose
that the object files
get stored as cc?<pid>, pid being a 5 digit
number representing the process ID (00550 in
your case) and "?" being a letter in the
range "a-z". So, if you have more then 26
files (and you do have about 30), temporary
object files start to overwrite each other
and linking fails because some object files are missing. "-fsave-temps"
apparently
uses a different algorithm for generating
temporary file names, so the problem does
not occur. I'd suppose that "-pipe" might
be able to solve the problem as well...

Regards,
Stefan
Christoph Schulte Moenting
2004-07-15 18:25:11 UTC
Permalink
Post by S***@public.gmane.org
Looking at the temporary file names in your failure log, I'd suppose
that the object files get stored as cc?<pid>
[snip]
Post by S***@public.gmane.org
"-fsave-temps" apparently uses a different algorithm for generating
temporary file names, so the problem does not occur.
You are right, -fsave-temps just stores the intermediate files e.g. as
builtins.i, builtins.s and builtins.o, so there is no conflict.
Post by S***@public.gmane.org
I'd suppose that "-pipe" might be able to solve the problem as well...
Nope, I just checked that: It then executes something like
"cpp builtins.c | cc1 | as > %TMP%\cc?<pid>", so I get the same problem
with overwritten temp files (actually, when it has reached ccz<pid>, it
just keeps that name).

Thanks for the hint, it's always nice to know why something fails. Does
anybody know if this is a "feature" of our emx/gcc (2.8.1) or if the
problem would also occur with gcc on a linux system?

Regards,
Christoph
S***@public.gmane.org
2004-07-16 10:15:06 UTC
Permalink
Post by Christoph Schulte Moenting
Thanks for the hint, it's always nice to know why
something fails. Does
anybody know if this is a "feature" of our emx/gcc
(2.8.1) or if the
problem would also occur with gcc on a linux system?
It's a limitation of the "mktemp" function that's apparently
used to generate the temporary names. Looking at the
temporary names used on other platforms, I suppose that
they are using the same function, so it's a general problem.

OTOH, it's pretty unusual to compile that many source code
files directly into the executable - no "make" based system
would do that (having to recompile _everything_ if just one
file changes is evil) - so I _guess_ the GCC team wouldn't
think it's worth the effort to fix it.

Regards,
Stefan
Christoph Schulte Moenting
2004-07-16 15:10:08 UTC
Permalink
Post by S***@public.gmane.org
OTOH, it's pretty unusual to compile that many source code
files directly into the executable - no "make" based system
would do that (having to recompile _everything_ if just one
file changes is evil) - so I _guess_ the GCC team wouldn't
think it's worth the effort to fix it.
I agree, it's quite unusual. They intend to use that makefile
just for bootstrapping, i.e. the makefile generates a "jam0"
executable that is already able to rebuild a full version of
Jam using Jamfiles instead of makefiles. So that makefile is
intended to be used only once.

Regards,
Christoph

Loading...