GCC 9.2.0 fails to link xul.dll

[dryeo]

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.

[dmik]

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.

[dryeo]

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.

[StevenLevine]

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.

[dryeo]

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]

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

[dryeo]

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.

[dmik]

@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]

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.

[dryeo]

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.

[dmik]

Closing in favor of the above ticket.