GCC 9.2.0 fails to link xul.dll #30

New Issue

claunia · 2026-01-29T22:23:43Z

claunia commented

2026-01-29 22:23:43 +00:00

Originally created by @dryeo on GitHub (Apr 12, 2020).

After trials and tribulations, I've got as far as linking xul.dll using the latest netlabs.exp stuff.
Linking fails pretty quick with this error,

92:34.46 emxomfld: _abspath failed on '@K:\var\temp/cc0sIIGI.'!!!
92:34.46 make.EXE[5]: *** [xul.dll] Error 1

Running make with a 4.9.2 GCC environment in $OBJDIR/toolkit/library works as well as expected, eventually dying due to unresolved symbols as expected as we're using different libgcc and stdc++.
To me it appears a failure of GCC writing the correct response file before calling emxomfld
While linking with 4.9.2, I find in $TMPDIR grsp0001.tmp containing the expected command line broken up on a per line basis.

Originally created by @dryeo on GitHub (Apr 12, 2020). After trials and tribulations, I've got as far as linking xul.dll using the latest netlabs.exp stuff. Linking fails pretty quick with this error, ``` 92:34.46 emxomfld: _abspath failed on '@K:\var\temp/cc0sIIGI.'!!! 92:34.46 make.EXE[5]: *** [xul.dll] Error 1 ``` Running make with a 4.9.2 GCC environment in $OBJDIR/toolkit/library works as well as expected, eventually dying due to unresolved symbols as expected as we're using different libgcc and stdc++. To me it appears a failure of GCC writing the correct response file before calling emxomfld While linking with 4.9.2, I find in $TMPDIR grsp0001.tmp containing the expected command line broken up on a per line basis.

claunia closed this issue

2026-01-29 22:23:43 +00:00

claunia commented

2026-01-29 22:23:44 +00:00

@dmik commented on GitHub (Apr 13, 2020):

You should extract the link command and add the -v argument to gcc/g++ to see how it calls emxomfld in 9.2.0. You should also do the same with gcc 4.9.2 to see the difference. It might be related to #14 but I'm not seeing how ATM.

@dmik commented on GitHub (Apr 13, 2020): You should extract the link command and add the `-v` argument to gcc/g++ to see how it calls emxomfld in 9.2.0. You should also do the same with gcc 4.9.2 to see the difference. It might be related to #14 but I'm not seeing how ATM.

claunia commented

2026-01-29 22:23:45 +00:00

@dryeo commented on GitHub (Apr 13, 2020):

What would be the best way to do that? Build a response file? The
command is pretty big and I guess it would involve nested response files.

@dryeo commented on GitHub (Apr 13, 2020): What would be the best way to do that? Build a response file? The command is pretty big and I guess it would involve nested response files.

claunia commented

2026-01-29 22:23:46 +00:00

@StevenLevine commented on GitHub (Apr 13, 2020):

What I do for this kind of testing is extract the failing command from the
log and stuff it into a sh.exe script. This makes it easy to wrap the
lines for readability and add anything needed to prepare any dependent
files the command line might need.

To run your script from cmd.exe or 4os2, it's:

sh -c 't.sh args'

whee t.sh is the script and args are any args that need to be passed. If
find this more efficient that setting sh.exe to the session shell. This
is what I used when working on your ::lldiv_t issue. You might recognize:

sh -c 't.sh -E -C'

from what we used to track down the #include issues.

@StevenLevine commented on GitHub (Apr 13, 2020): What I do for this kind of testing is extract the failing command from the log and stuff it into a sh.exe script. This makes it easy to wrap the lines for readability and add anything needed to prepare any dependent files the command line might need. To run your script from cmd.exe or 4os2, it's: sh -c 't.sh args' whee t.sh is the script and args are any args that need to be passed. If find this more efficient that setting sh.exe to the session shell. This is what I used when working on your ::lldiv_t issue. You might recognize: sh -c 't.sh -E -C' from what we used to track down the #include issues.

claunia commented

2026-01-29 22:23:46 +00:00

@dryeo commented on GitHub (Apr 13, 2020):

Ok, testing with GCC 5.5.0 as it also almost works with one missing
symbol from libgcc and I don't have to reboot.
The beginning of the emxomfld line differs in 5.5.0 not listing a
response file whereas 9.9.2 does, snippet from 5.5.0,

emxomfld.exe -Zmap -Zdll -o xul.dll 
O:/usr/bin/../lib/gcc/i686-pc-os2-emx/9/../../../dll0hi.obj 
@K:\var\temp/ccDLEvol -LO:/usr/bin/../lib/gcc/i686-pc-os2-emx/9 
-LO:/usr/bin/../lib/gcc 
-LO:/usr/bin/../lib/gcc/i686-pc-os2-emx/9/../../.. -L/@unixroot/usr/lib 
StaticXULComponentsStart.obj

From 5.5.0

emxomfld.exe -Zmap -Zdll -o xul.dll O:/USR/lib/dll0hi.obj 
-L/@unixroot/usr/lib 
-LO:/usr/local550/bin/../lib/gcc/i686-pc-os2-emx/5.5.0 
-LO:/usr/local550/bin/../lib/gcc -LO:/USR/local550/lib -LO:/USR/lib -L. 
-LO:/usr/local550/bin/../lib/gcc/i686-pc-os2-emx/5.5.0/../../.. 
StaticXULComponentsStart.obj

I'm leaving out the huge list of object files etc. This is the only
place I can find a reference to the response file besides the error at
the end.

@dryeo commented on GitHub (Apr 13, 2020): Ok, testing with GCC 5.5.0 as it also almost works with one missing symbol from libgcc and I don't have to reboot. The beginning of the emxomfld line differs in 5.5.0 not listing a response file whereas 9.9.2 does, snippet from 5.5.0, ``` emxomfld.exe -Zmap -Zdll -o xul.dll O:/usr/bin/../lib/gcc/i686-pc-os2-emx/9/../../../dll0hi.obj @K:\var\temp/ccDLEvol -LO:/usr/bin/../lib/gcc/i686-pc-os2-emx/9 -LO:/usr/bin/../lib/gcc -LO:/usr/bin/../lib/gcc/i686-pc-os2-emx/9/../../.. -L/@unixroot/usr/lib StaticXULComponentsStart.obj ``` From 5.5.0 ``` emxomfld.exe -Zmap -Zdll -o xul.dll O:/USR/lib/dll0hi.obj -L/@unixroot/usr/lib -LO:/usr/local550/bin/../lib/gcc/i686-pc-os2-emx/5.5.0 -LO:/usr/local550/bin/../lib/gcc -LO:/USR/local550/lib -LO:/USR/lib -L. -LO:/usr/local550/bin/../lib/gcc/i686-pc-os2-emx/5.5.0/../../.. StaticXULComponentsStart.obj ``` I'm leaving out the huge list of object files etc. This is the only place I can find a reference to the response file besides the error at the end.

claunia commented

2026-01-29 22:23:47 +00:00

@dryeo commented on GitHub (Apr 13, 2020):

Should also mention that the command line I'm using includes a response
file containing the 873 object files.

@dryeo commented on GitHub (Apr 13, 2020): Should also mention that the command line I'm using includes a response file containing the 873 object files.

claunia commented

2026-01-29 22:23:47 +00:00

@dryeo commented on GitHub (Apr 14, 2020):

Adding -DHAVE_GNU__LD to the compile line doesn't help.Running the
emxomfld line after removing the reference to the response file does
produce xul.dll.
I also tried replacing the list file in the GCC command with all the
object files but got "c++ invalid argument" likely due to a command line
over 40k long.

@dryeo commented on GitHub (Apr 14, 2020): Adding -DHAVE_GNU__LD to the compile line doesn't help.Running the emxomfld line after removing the reference to the response file does produce xul.dll. I also tried replacing the list file in the GCC command with all the object files but got "c++ invalid argument" likely due to a command line over 40k long.

claunia commented

2026-01-29 22:23:48 +00:00

@dmik commented on GitHub (Apr 14, 2020):

@dryeo what's in @k:\var\temp/ccDLEvol? A list of 873 object files on a single line, or each on a new line? Does it work if you run this emxomfld command manually? Or same error?

@dmik commented on GitHub (Apr 14, 2020): @dryeo what's in `@k:\var\temp/ccDLEvol`? A list of 873 object files on a single line, or each on a new line? Does it work if you run this emxomfld command manually? Or same error?

claunia commented

2026-01-29 22:23:49 +00:00

@dmik commented on GitHub (Apr 14, 2020):

Some testing shows that the problem might be in LIBC spawn code. Even this simple case:

emxomfld @D:/Temp/aaa

with the contents of aaa being just --help fails with:

emxomfld: _abspath failed on '@D:/Temp/aa.'!!!

but only if run from an .sh script (by sh.exe which uses spawn to start processes). If I use cmd instead, the problem disappears. kLIBC is known to do custom command line processing when both the parent and the child are kLIBC processes (not a wise decision to my taste, I've seen too many problems because of that already). And this is where handling of response files breaks for some reason. More debugging is needed but no time for that right now.

@dmik commented on GitHub (Apr 14, 2020): Some testing shows that the problem might be in LIBC spawn code. Even this simple case: ``` emxomfld @D:/Temp/aaa ``` with the contents of `aaa` being just `--help` fails with: ``` emxomfld: _abspath failed on '@D:/Temp/aa.'!!! ``` but only if run from an .sh script (by sh.exe which uses spawn to start processes). If I use cmd instead, the problem disappears. kLIBC is known to do custom command line processing when both the parent and the child are kLIBC processes (not a wise decision to my taste, I've seen too many problems because of that already). And this is where handling of response files breaks for some reason. More debugging is needed but no time for that right now.

claunia commented

2026-01-29 22:23:50 +00:00

@dryeo commented on GitHub (Apr 14, 2020):

On 04/14/20 05:06 AM, Dmitriy Kuminov wrote:

@dryeo https://github.com/dryeo what's in |@k:\var\temp/ccDLEvol|? A
list of 873 object files on a single line, or each on a new line? Does
it work if you run this emxomfld command manually? Or same error?

Never had a chance to examine |@k:\var\temp/ccDLEvol| as it is deleted
right away. The corresponding one from GCC 4.92 has each object file and
GCC command on its own line.
The emxomfld command only works without the response file.

@dryeo commented on GitHub (Apr 14, 2020): On 04/14/20 05:06 AM, Dmitriy Kuminov wrote: > @dryeo <https://github.com/dryeo> what's in |@k:\var\temp/ccDLEvol|? A > list of 873 object files on a single line, or each on a new line? Does > it work if you run this emxomfld command manually? Or same error? Never had a chance to examine |@k:\var\temp/ccDLEvol| as it is deleted right away. The corresponding one from GCC 4.92 has each object file and GCC command on its own line. The emxomfld command only works without the response file.

claunia commented

2026-01-29 22:23:51 +00:00

@dmik commented on GitHub (Apr 15, 2020):

Closing in favor of the above ticket.

@dmik commented on GitHub (Apr 15, 2020): Closing in favor of the above ticket.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bitwiseworks/gcc-os2#30