Paul Edwards
2020-04-03 12:58:58 UTC
Hi all.
I am receiving messages like this on my main project:
Info: resolving ***@0 by linking to ***@0 (auto-import)
nmth000000.o(.idata$4+0x0): undefined reference to `***@0'
which go away if I add __declspec(dllimport) to the prototype
for GetCommandLineA (etc).
They also go away if I build my kernel32.c
code with Cygwin gcc instead of my own
custom-built gcc 3.2.3.
I'm not sure if adding dllimport is the
correct technical solution or not. Or if
my gcc is broken (and if so, whether it can
be fixed).
I have simplified the problem to a test
case which you can see here:
C:\devel\pdos\src\zzz>type k.c
/*__declspec(dllexport)*/ int foo(void)
{
return (5);
}
C:\devel\pdos\src\zzz>type main.c
/*__declspec(dllimport)*/ int foo(void);
int main(void)
{
return (foo());
}
void __main(void)
{
}
C:\devel\pdos\src\zzz>doit
C:\devel\pdos\src\zzz>gccwin -nostdinc -S -Os -I . k.c
C:\devel\pdos\src\zzz>aswin -o k.o k.s
C:\devel\pdos\src\zzz>del k.s
C:\devel\pdos\src\zzz>rem for some reason gccwin is not generating the correct
C:\devel\pdos\src\zzz>rem assembler code, so we override with gcc 4.8.2 from Cygwin
C:\devel\pdos\src\zzz>rem gcc -nostdinc -c -Os -I . k.c
C:\devel\pdos\src\zzz>ldwin -s -o k.dll --shared --kill-at k.o
C:\devel\pdos\src\zzz>dlltwin -S aswin -k --export-all-symbols -D k.dll k.o -l libk.a
C:\devel\pdos\src\zzz>gccwin -S -Os -I . -o main.s main.c
C:\devel\pdos\src\zzz>aswin -o main.o main.s
C:\devel\pdos\src\zzz>del main.s
C:\devel\pdos\src\zzz>ldwin -s -o main.exe main.o -lk -L.
Info: resolving _foo by linking to __imp__foo (auto-import)
ldwin: warning: cannot find entry symbol _mainCRTStartup; defaulting to 00401000
fu000001.o(.idata$3+0xc): undefined reference to `libk_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__foo'
Any ideas?
Thanks. Paul.
I am receiving messages like this on my main project:
Info: resolving ***@0 by linking to ***@0 (auto-import)
nmth000000.o(.idata$4+0x0): undefined reference to `***@0'
which go away if I add __declspec(dllimport) to the prototype
for GetCommandLineA (etc).
They also go away if I build my kernel32.c
code with Cygwin gcc instead of my own
custom-built gcc 3.2.3.
I'm not sure if adding dllimport is the
correct technical solution or not. Or if
my gcc is broken (and if so, whether it can
be fixed).
I have simplified the problem to a test
case which you can see here:
C:\devel\pdos\src\zzz>type k.c
/*__declspec(dllexport)*/ int foo(void)
{
return (5);
}
C:\devel\pdos\src\zzz>type main.c
/*__declspec(dllimport)*/ int foo(void);
int main(void)
{
return (foo());
}
void __main(void)
{
}
C:\devel\pdos\src\zzz>doit
C:\devel\pdos\src\zzz>gccwin -nostdinc -S -Os -I . k.c
C:\devel\pdos\src\zzz>aswin -o k.o k.s
C:\devel\pdos\src\zzz>del k.s
C:\devel\pdos\src\zzz>rem for some reason gccwin is not generating the correct
C:\devel\pdos\src\zzz>rem assembler code, so we override with gcc 4.8.2 from Cygwin
C:\devel\pdos\src\zzz>rem gcc -nostdinc -c -Os -I . k.c
C:\devel\pdos\src\zzz>ldwin -s -o k.dll --shared --kill-at k.o
C:\devel\pdos\src\zzz>dlltwin -S aswin -k --export-all-symbols -D k.dll k.o -l libk.a
C:\devel\pdos\src\zzz>gccwin -S -Os -I . -o main.s main.c
C:\devel\pdos\src\zzz>aswin -o main.o main.s
C:\devel\pdos\src\zzz>del main.s
C:\devel\pdos\src\zzz>ldwin -s -o main.exe main.o -lk -L.
Info: resolving _foo by linking to __imp__foo (auto-import)
ldwin: warning: cannot find entry symbol _mainCRTStartup; defaulting to 00401000
fu000001.o(.idata$3+0xc): undefined reference to `libk_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__foo'
Any ideas?
Thanks. Paul.