[Mingw-users] weak functions

[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

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-use...@lists.sourceforge.net?subject=unsubscribe

[Earnie]

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

[Martin Whitaker]

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

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.

Take a complimentary Learning@Cisco Self-Assessment and learn

[Greg Chicares]

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.

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.

Take a complimentary Learning@Cisco Self-Assessment and learn

[Martin Whitaker]

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

[xunxun]

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

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.

Take a complimentary Learning@Cisco Self-Assessment and learn

[Martin Whitaker]

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

[xunxun]

于 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

[Earnie]

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

------------------------------------------------------------------------------

[Earnie]

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

------------------------------------------------------------------------------

[xunxun]

于 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

[Earnie]

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

------------------------------------------------------------------------------

[Martin Whitaker]

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 Whitaker]

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

[NightStrike]

On Sat, Oct 22, 2011 at 3:52 PM, Martin Whitaker
<mailin...@martin-whitaker.me.uk> 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.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure