On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote: > 2010/3/21 Ozkan Sezer <[email protected]>: > > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike <[email protected]> wrote: > >> Well, this is a problem, yes. It only affects the multilib builds, > >> though, which don't really work anyway without a lot of effort. And > >> this will all be fixed for 4.6, o we won't need to worry about it. > >> > >> If users really want it, though, I can rework things to exclude 32-bit > >> entirely. It's just a little messy in Makefile.am. > >> > >> On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler <[email protected]> wrote: > >>> Quick question: > >>> > >>> Are you sure you want to disable the leading underscore on the 32bit > >>> side with the --disable-leading-underscore and multilib? Looking at > >>> it (without testing it, that is), it doesn't seem to me that it is > >>> appropriate... > > > > I think the flag really should be added to the lib64 > > versions in the makefiles. Otherwise things would > > go far messier the may think of. > > I agree, that it maybe gets for x86 much messier. And if possible, it > would be better to have this underscoring just active for x64. > > > Besides that, there really is no way to tell the user > > as to how the crt was actually compiled. If there > > were a config header installed from within the crt > > build, maybe.. > > Hmm, for what this header should be? I see the issue that an user > can't see directly by which option for underscoring the crt was built, > but for this a header makes also no sense. To detect this a call of nm > reveals, if underscoring was active or not. > I don't think that we should introduce for this something in > configure. The header itself aren't affected, as they are checking the > underscoring mode of gcc directly.
It actually gets even messier. Currently, the ld in binutils assumes that x64 should always have underscores, which means that import and export symbols libraries are generated incorrectly from there. There's no way currently to configure at compile time or pass at runtime this flag to ld (unlike dlltool which at least has this). Nor is there a way to pass the flag from the gcc driver to the linker. I have patched ld (and the binutils configury) to accept a configure time parameter for default behavior, as well as adding a parameter to override the behavior from ld (which is more important). I am still waiting for copyright assignment paperwork from the FSF before I submit it for comment to the binutils list (not sure that this patch would be accepted though). This is in addition to the other two patches I have in my own pipeline with respect to the library long names (NULL terminated in PE-COFF) and the parameter to make ld import libraries generate the same archive member file name so that they can be picked up by the native linker (and I probably should figure a good way to patch dlltool to do this as well, but it uses a different method of generating import libraries...) ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
