OS/2, eCS & ArcaOS - Technical > Programming

GCC - updates

<< < (14/15) > >>

Paul Smedley:
Thanks Steven..

I updated LINK_SPEC to:

--- Code: ---#define LINK_SPEC                                                              \
  "%{Zexe} %{Zstack*} %{Zlinker*} %{Zmap*} %{Zsym} %{Zdll} %{shared:-Zdll} %{static:-static} " \
  "%{!o*:-o %w%b%{Zdll|shared:.dll}%{!Zdll:%{!shared:%{!Zexe:.exe}}}} "          \
  "%{static:%{Zcrtdll*:%e-static and -Zcrtdll are incompatible}}"              \
  "%{Zomf:%{Zaout:%e-Zomf and -Zaout are incompatible}}"                       \
  "%{Zdll:%{Zexe:%e-Zdll and -Zexe are incompatible}}"                         \
  "%{shared:%{Zexe:%e-shared and -Zexe are incompatible}}"                     \
  "%{Zsmall-conv:%{Zcrtdll*:%e-Zsmall-conv and -Zcrtdll are incompatible}}"

--- End code ---

But now I get

--- Code: ---{0}[u:\dev\gcc-os2-14.x] gcc -Zexe helloworld.c
ld.exe: No such file or directory for .exe
Assertion failed: crumb->x.used.size <= crate->crumb_size, file ./libc-0.1.12/src/emx/src/lib/malloc/ifree.c, line 65

--- End code ---

and sure enough adding -t -t gives:

--- Code: ---Invoking emxbind: emxbind -bq -o .exe C:\var\temp/ccgEvumKldXXXXXX
ld.exe: No such file or directory for .exe

--- End code ---

Dave Yeo:
What about without -Zexe? -Zexe exists only to work around makefiles that don't know about exeext or .exe, so not only foo gets built but also foo.exe. Starting with GCC 2.9.x foo became an executable stub pointing to foo.exe.
Should almost never need it now.

Steven Levine:
FWIW, running

  gcc -v -Zexe helloworld.c

will give better debugging output for this issue.

Also, it occurs to me that rather than rebuilds gcc, we can experiment with the specs by running

  gcc -specs=my.specs -v -Zexe helloworld.c

where my.specs is the edited output of

  gcc -dumpspecs >my.specs

I'll experiment with this and see what is revealed.

The missing basename implies that for:

gcc\gcc.cc:6168
       if (this_is_output_file || !outbase_length)
         obstack_grow (&obstack, input_basename, basename_length);
       else
         obstack_grow (&obstack, outbase, outbase_length);

neither input_basename or outbase is getting set.  This is unexpected since it appears that in 9.2.0 input_basename was
providing the value for %b.

Paul Smedley:
It's interesting - at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L8196 suffixed_basename_length has been set (in the case of helloworld.c to 12)  but by https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6291 it's 0.

Weird.

the positive is that if I set '  suffixed_basename_length = 10;' at L6291 then we do get a valid helloworld.exe....

Paul Smedley:
OK suffixed_basename_length is being reset to 0 here - https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L9319

I'm thinking in hindsignt that the comment at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/gcc.cc#L6289 "Don't use %b in the linker command" is perhaps a sign that for whatever reason,  we should not be using %b in the linker command - which we clearly are at https://github.com/psmedley/gcc-os2/blob/gcc-14.x/gcc/config/i386/emx.h#L447

So... we need to re-think how to get the output file name to match the source file name - or accept that we match the defaults on other OS....

Navigation

[0] Message Index

[#] Next page

[*] Previous page