| Summary: | -fno-leading-underscore ignored | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Adrian May <adrian.alexander.may> |
| Component: | c | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P3 | ||
| Version: | 3.4.4 | ||
| Target Milestone: | 4.5.0 | ||
| Host: | Cygwin | Target: | Cygwin |
| Build: | Cygwin | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
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. |
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.