linking errors (cross compiling to NT)

[Jens Staal]

Hi

For fun and for learning, I have tried porting busybox-w32 to build with
Open Watcom (using the MinGW port a lot).

https://github.com/staalmannen/busybox-w32/tree/watcom

If anyone is interested in trying/playing, it still depends on a Linux host,
GCC as HOSTCC and GNU make... those things might be adressed later. Right
now owcc is basically just used as an alternative to mingw as cross-
compiler.
There are probably lots of hacks that smarter and more experienced people
could make nicer / eliminate.

The current status is that everything build, but when I link I get the
following:

Open Watcom Linker Version 2.0 beta Oct 29 2014 15:12:20 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
Warning! W1023: no starting address found, using 00401000
creating a Windows NT character-mode executable
Error! E3009: dynamic memory exhausted

I suppose this means that the watcom equivalent of crt0 is not present in
the linking. Is there a way that I can "force" this? I looked at the startup
examples in the Watcom src directory but did not get any wiser... I suppose
there should be such an object in libc?

[Wilton Helm]

I'm not sure the warning is fatal. Generally a startup file is linked in to
resolve a label created by the compiler for that purpose. The startup file
initializes the environment needed by the program and ties it to the OS. It
can contain a directive to provide a starting address.

I'd be more concerned about the (probably unrelated) dynamic memory
exhaustion. It sounds like this is a fairly large project. Dynamic memory
is used by the linker to assemble segment fragments as they are encountered.
as well as maintain symbol lists, etc. The linker allocates a bunch of
lists. On limited systems, like DOS, it actually includes a mechanism for
using a temporary file for this purpose (obviously slower), but for OSs like
Windows it just keeps asking the OS for more memory. The OS can spool stuff
out to disk to make room if it needs to. Clearly having a lot or RAM is
beneficial, but lacking that, making sure it has access to enough virtual
memory should avoid the failure. Like the DOS based file solution, it will
be slower, because of thrashing, but slow is better than failed.

Wilton

Post by Jens Staal
Hi
For fun and for learning, I have tried porting busybox-w32 to build with
Open Watcom (using the MinGW port a lot).
https://github.com/staalmannen/busybox-w32/tree/watcom
If anyone is interested in trying/playing, it still depends on a Linux host,
GCC as HOSTCC and GNU make... those things might be adressed later. Right
now owcc is basically just used as an alternative to mingw as cross-
compiler.
There are probably lots of hacks that smarter and more experienced people
could make nicer / eliminate.
The current status is that everything build, but when I link I get the
Open Watcom Linker Version 2.0 beta Oct 29 2014 15:12:20 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
Warning! W1023: no starting address found, using 00401000
creating a Windows NT character-mode executable
Error! E3009: dynamic memory exhausted
I suppose this means that the watcom equivalent of crt0 is not present in
the linking. Is there a way that I can "force" this? I looked at the startup
examples in the Watcom src directory but did not get any wiser... I suppose
there should be such an object in libc?

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

[Paul S. Person]

On Wed, 19 Nov 2014 10:40:11 -0700, "Wilton Helm"

Post by Wilton Helm
I'm not sure the warning is fatal. Generally a startup file is linked in to
resolve a label created by the compiler for that purpose. The startup file
initializes the environment needed by the program and ties it to the OS. It
can contain a directive to provide a starting address.
I'd be more concerned about the (probably unrelated) dynamic memory
exhaustion. It sounds like this is a fairly large project. Dynamic memory
is used by the linker to assemble segment fragments as they are encountered.
as well as maintain symbol lists, etc. The linker allocates a bunch of
lists. On limited systems, like DOS, it actually includes a mechanism for
using a temporary file for this purpose (obviously slower), but for OSs like
Windows it just keeps asking the OS for more memory. The OS can spool stuff
out to disk to make room if it needs to. Clearly having a lot or RAM is
beneficial, but lacking that, making sure it has access to enough virtual
memory should avoid the failure. Like the DOS based file solution, it will
be slower, because of thrashing, but slow is better than failed.

In Windows, Task Manager should be able to show if memory is, in fact,
being exhausted. Although, in my experience with certain
overly-optimistic video editing programs that also just kept asking
for more memory, if you are running out of memory you will notice it.

If Task Manager shows that the total amount of memory, including the
swap file, is being exhaused then, for Windows, if you have the disk
space, you can increase the allowed size of the swap file. Note that
you can have several swap files, on different partitions, if needed.

If you are out of RAM and out of disk space, though, then you've had
it. Well, unless you are willing to buy an additional hard drive and
use that for yet another swap file. With USB 3 2-TB drives available
at what I would regard as a quite reasonable price, this shouldn't be
all that hard ... if you have or can add a USB 3 port. But drives
using two USB 2 ports with a Y-cable aren't exactly hard to find
either.

[Jens Staal]

Post by Wilton Helm
'm not sure the warning is fatal. Generally a startup file is linked in
to resolve a label created by the compiler for that purpose. The startup
file initializes the environment needed by the program and ties it to the
OS. It can contain a directive to provide a starting address.
I'd be more concerned about the (probably unrelated) dynamic memory
exhaustion. It sounds like this is a fairly large project. Dynamic
memory is used by the linker to assemble segment fragments as they are
encountered. as well as maintain symbol lists, etc. The linker allocates
a bunch of lists.

Actually I am almost a bit embarrassed to report that the solution was
rather simple:

The kbuild system had bundled the object file containing main() in an
intermediate library, so wlink could not find a starting point.
This probably does not happen with the intended compiler (gcc), and kbuild
seems to heavily rely on "ld -r" type of incremental linking to bundle
several object files into one before the final linking.

Explicitly pointing out the object file containing main() in my wlink linker
script removed both errors...

Now I am at the "...is an unidentified reference" whack-a-mole stage of
linking ;)

[Jens Staal]

Post by Jens Staal
Now I am at the "...is an unidentified reference" whack-a-mole stage of
linking ;)

I have resolved everything except one annoying issue. Two symbols in
kernel32.lib does not seem to be mangled the "normal" way and linking fails.

I tried to solve it with a wlink script

alias GetConsoleProcessList_=_GetConsoleProcessList
alias GetConsoleWindow_=_GetConsoleWindow

but that did not help. Most likely the re-definition needs to be at the time
the object file gets compiled (the object file is part of a larger library)
and not when the library gets linked.

Is there an alternative way to get the correct symbol names in that specific
object file (with for example a #pragma)?

[d3x0r]

Post by Jens Staal

Post by Jens Staal
Now I am at the "...is an unidentified reference" whack-a-mole stage of
linking ;)

I have resolved everything except one annoying issue. Two symbols in
kernel32.lib does not seem to be mangled the "normal" way and linking fails.
I tried to solve it with a wlink script
alias GetConsoleProcessList_=_GetConsoleProcessList
alias GetConsoleWindow_=_GetConsoleWindow

This looks like maybe you missed an include... functinos with postfixed _
are watcom register calltype; this is teh default... the windows headers
all specifcy __cdecl or __stdcall (WINAPI/CALLBACK/etc) appropriately....
so I'd think you missed a warning about missing function defintion, and it
guessed.

Post by Jens Staal
but that did not help. Most likely the re-definition needs to be at the time
the object file gets compiled (the object file is part of a larger library)
and not when the library gets linked.
Is there an alternative way to get the correct symbol names in that specific
object file (with for example a #pragma)?

[Jens Staal]

Post by d3x0r
This looks like maybe you missed an include... functinos with postfixed _
are watcom register calltype; this is teh default... the windows headers
all specifcy __cdecl or __stdcall (WINAPI/CALLBACK/etc) appropriately....
so I'd think you missed a warning about missing function defintion, and it
guessed.

Thanks this was indeed the issue.
I had missed that the functions that failed to link were hidden behind

#if (_WIN32_WINNT >= 0x0501)

in the header

Defining that made the linking work.