Bug 41692 - -fno-leading-underscore ignored
Summary: -fno-leading-underscore ignored
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.4.4
: P3 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-13 04:43 UTC by Adrian May
Modified: 2009-10-13 05:04 UTC (History)
1 user (show)

See Also:
Host: Cygwin
Target: Cygwin
Build: Cygwin
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian May 2009-10-13 04:43:36 UTC
That sums it up really. On Linux everything is fine, but on Windows this flag is ignored. To reproduce, just compile void foo() {} with and without the flag, nm the resulting obj and see that the underscore is always there.

This is a problem for me because I'm mixing nasm and c and hoping to build on both linux and windows. The linux version doesn't use leading underscores anyway, but the windows version does. Why? Why don't they behave the same and save all the hassle? I could tell my nasm code to import symbols with underscores, but then the linux version would break. I tried telling the linux version to use the underscores, but the linker still expected none and couldn't link between c files. The linker wouldn't be told to expect underscores unless it was making a shared library. This is all just obscuring the code and I see no reason for the difference. Even if the difference is justified, at the very least -fno-leading-underscores should work.

I don't really have the option of using a different gcc version because I just let the cygwin installer decide that and I don't want to break it. Besides, my customers wouldn't want that adventure either. So it looks like I'm stuffed all round.
Comment 1 Dave Korn 2009-10-13 05:04:19 UTC
It is not appropriate to add a mailing list as a Cc to a bugzilla entry, so I've removed that from the CC list.

On the other hand, I have some good news for you; this has been fixed in SVN and will be working in the next release of GCC.