From: Martin W. <mai...@ma...> - 2011-10-20 08:01:20
|
I am trying to build some code that uses weak functions. To give a simple example, take the following two files: file1.c: #include <stdio.h> void myfunc(void) __attribute__((weak)); void myfunc(void) { printf("myfunc called\n"); } file2.c: extern void myfunc(void); int main(int argc, char *argv[]) { myfunc(); } When trying to compile and link in a MinGW shell, I get: $ gcc -c -o file1.o file1.c $ gcc -c -o file2.o file2.c $ gcc file1.o file2.o file2.o:file2.c:(.text+0xc): undefined reference to `myfunc' collect2: ld returned 1 exit status Listing the symbols in file1.o, I get: % nm file1.o 00000000 b .bss 00000000 d .data 00000000 r .rdata 00000000 t .text 00000000 T .weak._myfunc. w _myfunc U _puts which suggests the fault is in 'ld'. Searching the mailing list archives, I found a post in mingw.devel from Aaron W. LaFramboise in 2004 entitled "Weak symbols done", which states that weak symbols should now work correctly in all cases. So is this a regression, or was this particular use case never supported? Martin |
From: Earnie <ea...@us...> - 2011-10-20 11:30:48
|
Martin Whitaker wrote: > > $ gcc -c -o file1.o file1.c > $ gcc -c -o file2.o file2.c > $ gcc file1.o file2.o > file2.o:file2.c:(.text+0xc): undefined reference to `myfunc' > collect2: ld returned 1 exit status > Common user error: Command line order. This has nothing to do with weak symbols and everything to do with how you've specified the objects on the command line. http://www.mingw.org/wiki/The_linker_consistently_giving_undefined_references gcc file2.o file1.o This should resolve the issue. -- Earnie -- http://www.for-my-kids.com |
From: Martin W. <mai...@ma...> - 2011-10-20 17:51:41
|
Earnie wrote: > Martin Whitaker wrote: >> >> $ gcc -c -o file1.o file1.c >> $ gcc -c -o file2.o file2.c >> $ gcc file1.o file2.o >> file2.o:file2.c:(.text+0xc): undefined reference to `myfunc' >> collect2: ld returned 1 exit status >> > > Common user error: Command line order. > > This has nothing to do with weak symbols and everything to do with how > you've specified the objects on the command line. > http://www.mingw.org/wiki/The_linker_consistently_giving_undefined_references > That only applies to libraries. I deliberately avoided using libraries in my simplified example to eliminate such issues. > gcc file2.o file1.o > > This should resolve the issue. > I afraid not: $ gcc file2.o file1.o file2.o:file2.c:(.text+0xc): undefined reference to `myfunc' collect2: ld returned 1 exit status I've tested the same code in Linux, and it works with either command line order. Martin |
From: Earnie <ea...@us...> - 2011-10-21 18:48:56
|
Martin Whitaker wrote: > Earnie wrote: >> Martin Whitaker wrote: >>> >>> $ gcc -c -o file1.o file1.c >>> $ gcc -c -o file2.o file2.c >>> $ gcc file1.o file2.o >>> file2.o:file2.c:(.text+0xc): undefined reference to `myfunc' >>> collect2: ld returned 1 exit status >>> >> >> Common user error: Command line order. >> >> This has nothing to do with weak symbols and everything to do with how >> you've specified the objects on the command line. >> http://www.mingw.org/wiki/The_linker_consistently_giving_undefined_references >> > That only applies to libraries. I deliberately avoided using libraries in my > simplified example to eliminate such issues. > Duh!! > > I've tested the same code in Linux, and it works with either command line order. > Comparing results from Linux with results from Windows is like comparing the taste of an olive to the taste of a banana. -- Earnie -- http://www.for-my-kids.com |
From: Greg C. <gch...@sb...> - 2011-10-20 18:06:01
|
On 2011-10-20 08:01Z, Martin Whitaker wrote: [...] > Searching the mailing list archives, I found a post in mingw.devel from Aaron > W. LaFramboise in 2004 entitled "Weak symbols done", which states that weak > symbols should now work correctly in all cases. So is this a regression, or > was this particular use case never supported? Your [snipped] testcase works fine for me with MinGW gcc-4.5.0 and ld-2.20.51.20100613. If you're using later versions of mingw.org tools, then this would appear to be a regression. |
From: Martin W. <mai...@ma...> - 2011-10-20 18:17:47
|
Greg Chicares wrote: > On 2011-10-20 08:01Z, Martin Whitaker wrote: > [...] >> Searching the mailing list archives, I found a post in mingw.devel from Aaron >> W. LaFramboise in 2004 entitled "Weak symbols done", which states that weak >> symbols should now work correctly in all cases. So is this a regression, or >> was this particular use case never supported? > > Your [snipped] testcase works fine for me with MinGW gcc-4.5.0 and > ld-2.20.51.20100613. If you're using later versions of mingw.org > tools, then this would appear to be a regression. > Thanks for testing this Greg. I'm using MinGW gcc 4.5.2 and ld 2.21. I'll see if I can install an older version to confirm the regression. Martin |
From: Martin W. <mai...@ma...> - 2011-10-22 19:50:46
|
Martin Whitaker wrote: > Greg Chicares wrote: >> On 2011-10-20 08:01Z, Martin Whitaker wrote: >> [...] >>> Searching the mailing list archives, I found a post in mingw.devel >>> from Aaron >>> W. LaFramboise in 2004 entitled "Weak symbols done", which states >>> that weak >>> symbols should now work correctly in all cases. So is this a >>> regression, or >>> was this particular use case never supported? >> >> Your [snipped] testcase works fine for me with MinGW gcc-4.5.0 and >> ld-2.20.51.20100613. If you're using later versions of mingw.org >> tools, then this would appear to be a regression. >> > Thanks for testing this Greg. I'm using MinGW gcc 4.5.2 and ld 2.21. > I'll see if I can install an older version to confirm the regression. > When I reverted to gcc 4.5.0 and ld 2.20.51, I still got the same error. Could you post the output of objdump -t file1.o to see if that gives any clues. Thanks, Martin |
From: xunxun <xun...@gm...> - 2011-10-20 18:28:25
|
于 2011/10/20 16:01, Martin Whitaker 写道: > I am trying to build some code that uses weak functions. To give a simple > example, take the following two files: > > file1.c: > > #include<stdio.h> > void myfunc(void) __attribute__((weak)); > void myfunc(void) > { > printf("myfunc called\n"); > } > > file2.c: > > extern void myfunc(void); > int main(int argc, char *argv[]) > { > myfunc(); > } > > When trying to compile and link in a MinGW shell, I get: > > $ gcc -c -o file1.o file1.c > $ gcc -c -o file2.o file2.c > $ gcc file1.o file2.o > file2.o:file2.c:(.text+0xc): undefined reference to `myfunc' > collect2: ld returned 1 exit status > > Listing the symbols in file1.o, I get: > > % nm file1.o > 00000000 b .bss > 00000000 d .data > 00000000 r .rdata > 00000000 t .text > 00000000 T .weak._myfunc. > w _myfunc > U _puts > > which suggests the fault is in 'ld'. > > Searching the mailing list archives, I found a post in mingw.devel from Aaron > W. LaFramboise in 2004 entitled "Weak symbols done", which states that weak > symbols should now work correctly in all cases. So is this a regression, or > was this particular use case never supported? > > Martin I think it's a mingw target ld bug. If you have time, could you test the latest binutils snapshots, if it also has the problem, you can report it to http://sourceware.org/bugzilla/ -- Best Regards, xunxun |
From: Martin W. <mai...@ma...> - 2011-10-20 18:35:21
|
xunxun wrote: > 于 2011/10/20 16:01, Martin Whitaker 写道: >> I am trying to build some code that uses weak functions. To give a simple >> example, take the following two files: ... >> which suggests the fault is in 'ld'. >> >> Searching the mailing list archives, I found a post in mingw.devel >> from Aaron >> W. LaFramboise in 2004 entitled "Weak symbols done", which states that >> weak >> symbols should now work correctly in all cases. So is this a >> regression, or >> was this particular use case never supported? >> >> Martin > I think it's a mingw target ld bug. > If you have time, could you test the latest binutils snapshots, if it > also has the problem, you can report it to http://sourceware.org/bugzilla/ > Hi xunxun, I've just upgraded to binutils 2.21.53.20110804 which still has the same problem. Is there a more recent snapshot than this? Thanks, Martin |
From: xunxun <xun...@gm...> - 2011-10-20 18:42:20
|
于 2011/10/21 2:35, Martin Whitaker 写道: > Hi xunxun, > > I've just upgraded to binutils 2.21.53.20110804 which still has the > same problem. Is there a more recent snapshot than this? > > Thanks, I don't know whether there is the prebuilt package, but about source code, you can get from ftp://sourceware.org/pub/binutils/snapshots/ You can build it yourself. -- Best Regards, xunxun |
From: Earnie <ea...@us...> - 2011-10-21 18:44:57
|
xunxun wrote: > 于 2011/10/21 2:35, Martin Whitaker 写道: >> Hi xunxun, >> >> I've just upgraded to binutils 2.21.53.20110804 which still has the >> same problem. Is there a more recent snapshot than this? >> >> Thanks, > I don't know whether there is the prebuilt package, but about source > code, you can get from ftp://sourceware.org/pub/binutils/snapshots/ > > You can build it yourself. > > Using --enable-extra-pe-debug ld switch I found the symbol defined as .weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the binary was built and executes. So why the extra "." symbol on the end? Whose at fault GCC for the extra "." or binutils for ignoring it? -- Earnie -- http://www.for-my-kids.com |
From: xunxun <xun...@gm...> - 2011-10-22 03:40:38
|
于 2011/10/22 2:44, Earnie 写道: > Using --enable-extra-pe-debug ld switch I found the symbol defined as > .weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the > binary was built and executes. So why the extra "." symbol on the end? > Whose at fault GCC for the extra "." or binutils for ignoring it? So may someone report to binutils bugzilla? Or Kai may look into this issue? -- Best Regards, xunxun |
From: Earnie <ea...@us...> - 2011-10-22 16:30:48
|
xunxun wrote: > 于 2011/10/22 2:44, Earnie 写道: >> Using --enable-extra-pe-debug ld switch I found the symbol defined as >> .weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the >> binary was built and executes. So why the extra "." symbol on the end? >> Whose at fault GCC for the extra "." or binutils for ignoring it? > So may someone report to binutils bugzilla? > I don't have more time for it but I can tell you that gas is the culprit for adding the '.'. It isn't in the generated file1.s file. > Or Kai may look into this issue? > We can hope. -- Earnie -- http://www.for-my-kids.com |
From: Martin W. <mai...@ma...> - 2011-10-22 19:52:35
|
xunxun wrote: > 于 2011/10/22 2:44, Earnie 写道: >> Using --enable-extra-pe-debug ld switch I found the symbol defined as >> .weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the >> binary was built and executes. So why the extra "." symbol on the end? >> Whose at fault GCC for the extra "." or binutils for ignoring it? > So may someone report to binutils bugzilla? > I've found an existing bug report for this: http://sourceware.org/bugzilla/show_bug.cgi?id=9687 Reading that, it doesn't seem that the extra "." is the problem (and patching gas to eliminate the extra "." did not fix it). Unfortunately the bug report dates back to 2008, so it doesn't look like there's any impetus to fix it. Martin |
From: NightStrike <nig...@gm...> - 2012-03-22 11:58:57
|
On Sat, Oct 22, 2011 at 3:52 PM, Martin Whitaker <mai...@ma...> wrote: > xunxun wrote: >> 于 2011/10/22 2:44, Earnie 写道: >>> Using --enable-extra-pe-debug ld switch I found the symbol defined as >>> .weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the >>> binary was built and executes. So why the extra "." symbol on the end? >>> Whose at fault GCC for the extra "." or binutils for ignoring it? >> So may someone report to binutils bugzilla? >> > I've found an existing bug report for this: > > http://sourceware.org/bugzilla/show_bug.cgi?id=9687 > > Reading that, it doesn't seem that the extra "." is the problem (and patching > gas to eliminate the extra "." did not fix it). > > Unfortunately the bug report dates back to 2008, so it doesn't look like > there's any impetus to fix it. > > Martin Kai, would you mind taking a look at this binutils bug and seeing if there's a way to resolve it? Martin has been having a problem since October. |
From: Kai T. <kti...@go...> - 2012-03-22 14:13:21
|
2012/3/22 NightStrike <nig...@gm...>: > On Sat, Oct 22, 2011 at 3:52 PM, Martin Whitaker > <mai...@ma...> wrote: >> xunxun wrote: >>> 于 2011/10/22 2:44, Earnie 写道: >>>> Using --enable-extra-pe-debug ld switch I found the symbol defined as >>>> .weak._myfunc. so I then added --defsym _myfunc=.weak._myfunc. and the >>>> binary was built and executes. So why the extra "." symbol on the end? >>>> Whose at fault GCC for the extra "." or binutils for ignoring it? >>> So may someone report to binutils bugzilla? >>> >> I've found an existing bug report for this: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=9687 >> >> Reading that, it doesn't seem that the extra "." is the problem (and patching >> gas to eliminate the extra "." did not fix it). >> >> Unfortunately the bug report dates back to 2008, so it doesn't look like >> there's any impetus to fix it. >> >> Martin > > Kai, would you mind taking a look at this binutils bug and seeing if > there's a way to resolve it? Martin has been having a problem since > October. Well, I am aware of that issue. I tried once to investigate this in more detail, but had to find out that if I change this '.' issue I would break cygwin badly. Point is that a weak symbol gets decorated by an '.'<extension> for its implemenation and then this symbol is defined as weak. Kai |