Dear MinGW-w64 developers,
When compiling the Linux kernel with MinGW-w64, I came across something
that looks like a MinGW-w64 bug (either in the compiler or the linker).
When compiling and linking those 2 C files:
// foo.c:
#include "foo.h"
int __attribute__((weak)) foo(void)
{
return 42;
}
int __attribute__((weak)) bar(void)
{
return 69;
}
// foobar.c:
#include "foo.h"
#include <stdio.h>
int main(void)
{
printf("foo is %d\n", foo());
printf("bar is %d\n", bar());
}
// header foo.h is:
int foo(void);
int __attribute__((weak)) bar(void);
the foo symbol is not defined when linking. The error
message is:
/usr/lib/gcc/i686-w64-mingw32/14.2.1/../../../../i686-w64-mingw32/bin/ld:
foobar.o:foobar.c:(.text+0x4b): undefined reference to `foo'
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: foobar] Error 1
The difference is that bar is declared weak also in the foo.h
header file while foo is not. The objdump of the foobar.o file
lists a (suspicious) entry:
[ 17](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 .weak._bar._main
for bar but not for foo. This might be a hint for what is going wrong.
I've put the reproducer project on github for your convenience:
https://github.com/johannesthoma/mingw-weaktest.git
Note that with a (for example) Linux gcc, this undefined reference does not
happen.
So, my questions are:
* is this a real bug? Or is it just a different point of view onto how weak
symbols are handled?
* If it is a bug, can I help somehow to fix it?
* If it is not a bug, what (except for declaring all possible symbols as
__weak
which I want to avoid, because there are a LOT in the Linux kernel) would be
a workaround (some compiler/linker flags maybe?)
Thank you for your attention.
Best regards,
- Johannes
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
