From: Doug S. <dou...@gm...> - 2010-03-21 16:24:15
|
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... |
From: NightStrike <nig...@gm...> - 2010-03-21 17:21:20
|
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 <dou...@gm...> 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... > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: Ozkan S. <se...@gm...> - 2010-03-21 17:49:34
|
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike <nig...@gm...> 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 <dou...@gm...> 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. 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.. -- Ozkan |
From: Kai T. <kti...@go...> - 2010-03-21 17:55:44
|
2010/3/21 Ozkan Sezer <se...@gm...>: > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike <nig...@gm...> 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 <dou...@gm...> 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. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2010-03-21 18:07:33
|
On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz <kti...@go...> wrote: > 2010/3/21 Ozkan Sezer <se...@gm...>: >> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike <nig...@gm...> 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 <dou...@gm...> 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. > You mean that we should make no-underscore the default 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. Yes, _mingw_mac.h does that, figures what mode gcc is currently in. A generated header from crt compile time would be designed to indicate how it was compiled would be helpful to user: Suppose you compile a tree but the result was a link failure after one or two hours, how many remaining teeth would the user have after such an experience? > > Kai > > > -- > | (\_/) This is Bunny. Copy and paste > | (='.'=) Bunny into your signature to help > | (")_(") him gain world domination > -- Ozkan |
From: Doug S. <dou...@gm...> - 2010-03-21 18:10:44
|
On Sun, 21 Mar 2010 13:21:12 NightStrike 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. > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The target DLLs for things like libstdc++, etc are installed into the completely wrong spot due to a -bindir parameter in the libtool portion of the DLL makefiles. They are installed into the host's binary directory (which makes no sense to me at all - by the way I use a different -prefix and -exec-prefix), they cannot be overridden by the --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden and which I have working multilib with a minor patch to gcc/config/t-cygming), nor do they obey the version specific runtime libs directory like the native toolchain does. In addition, the mulitlib install can clobber the dlls in that (wrong) bindir with the wrong arch type (the 32bit install puts the 64 bit version there after all is said and done). Given that the trunk of GCC is in stage 4, I wouldn't expect any of this to be fixed prior to the release even if patches were submitted since I wouldn't expect this to be classified as a P1 issue (I don't think the w64-mingw32 toolchain is considered to be a primary target, is it?) My frustration right now is that the GCC trunk has been in stage 4 since December...aside from the fact that I would be wary personally of moving to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for these targets... After saying all that, the documentation about multilib should maybe have some caveats... |
From: NightStrike <nig...@gm...> - 2010-03-21 22:37:20
|
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> wrote: > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The > target DLLs for things like libstdc++, etc are installed into the completely > wrong spot due to a -bindir parameter in the libtool portion of the DLL > makefiles. They are installed into the host's binary directory (which makes no > sense to me at all - by the way I use a different -prefix and -exec-prefix), they > cannot be overridden by the --with-slibdir (unlike the libgcc-sjlj-1.dll, > which can be overridden and which I have working multilib with a minor patch > to gcc/config/t-cygming), nor do they obey the version specific runtime libs > directory like the native toolchain does. In addition, the mulitlib install > can clobber the dlls in that (wrong) bindir with the wrong arch type (the > 32bit install puts the 64 bit version there after all is said and done). Jon Y has a patch for all of that. > Given that the trunk of GCC is in stage 4, I wouldn't expect any of this to > be fixed prior to the release even if patches were submitted since I wouldn't > expect this to be classified as a P1 issue (I don't think the w64-mingw32 > toolchain is considered to be a primary target, is it?) Yeah, it's not getting fixed in 4.5. And no, we aren't even a secondary target :( > My frustration right now is that the GCC trunk has been in stage 4 since > December...aside from the fact that I would be wary personally of moving to a > stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for these > targets... > > After saying all that, the documentation about multilib should maybe have some > caveats... > Well, to be fair, we never advertised that it even exists... so..... |
From: Doug S. <dou...@gm...> - 2010-03-21 23:24:45
|
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: > On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> wrote: > > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The > > target DLLs for things like libstdc++, etc are installed into the > > completely wrong spot due to a -bindir parameter in the libtool portion > > of the DLL makefiles. They are installed into the host's binary > > directory (which makes no sense to me at all - by the way I use a > > different -prefix and -exec-prefix), they cannot be overridden by the > > --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden > > and which I have working multilib with a minor patch to > > gcc/config/t-cygming), nor do they obey the version specific runtime > > libs directory like the native toolchain does. In addition, the > > mulitlib install can clobber the dlls in that (wrong) bindir with the > > wrong arch type (the 32bit install puts the 64 bit version there after > > all is said and done). > > Jon Y has a patch for all of that. > > > Given that the trunk of GCC is in stage 4, I wouldn't expect any of this > > to be fixed prior to the release even if patches were submitted since I > > wouldn't expect this to be classified as a P1 issue (I don't think the > > w64-mingw32 toolchain is considered to be a primary target, is it?) > > Yeah, it's not getting fixed in 4.5. And no, we aren't even a > secondary target :( > > > My frustration right now is that the GCC trunk has been in stage 4 since > > December...aside from the fact that I would be wary personally of moving > > to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for > > these targets... > > > > After saying all that, the documentation about multilib should maybe have > > some caveats... > > Well, to be fair, we never advertised that it even exists... so..... In both how-to-build docs, yes, you do :) I know that there was the "the tools now track gcc" statement and "no more need to patch gcc." One of the problems really is going to be requiring the use of the 4.6 trunk to get the correct behavior for installation of the toolchain (multilib notwithstanding, I still feel the installation of the target DLLs is also woefully incorrect, so I presume the patch mentioned above does that as well) unless there are also plans to backport them to 4.5, which I would doubt. I would never use the stage 1,2, or 3 trunks to build production code (well, maybe the stage 3 depending on the issues in it)-- they are just too unstable --which means I'll track the 4.5 branch for quite a while. Don't know what I'll do...wait for the patch(es) to be applied, do the work myself, or just deal with it (using nonmultilib, moving the files to where they should be, and modifying the installed .la files correctly...) OK...vent mode off :) |
From: JonY <jo...@us...> - 2010-03-22 00:48:30
Attachments:
v1.patch
gcc_multilib.patch
|
On 3/22/2010 07:24, Doug Semler wrote: > On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: >> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler<dou...@gm...> wrote: >>> Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The >>> target DLLs for things like libstdc++, etc are installed into the >>> completely wrong spot due to a -bindir parameter in the libtool portion >>> of the DLL makefiles. They are installed into the host's binary >>> directory (which makes no sense to me at all - by the way I use a >>> different -prefix and -exec-prefix), they cannot be overridden by the >>> --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden >>> and which I have working multilib with a minor patch to >>> gcc/config/t-cygming), nor do they obey the version specific runtime >>> libs directory like the native toolchain does. In addition, the >>> mulitlib install can clobber the dlls in that (wrong) bindir with the >>> wrong arch type (the 32bit install puts the 64 bit version there after >>> all is said and done). >> >> Jon Y has a patch for all of that. >> >>> Given that the trunk of GCC is in stage 4, I wouldn't expect any of this >>> to be fixed prior to the release even if patches were submitted since I >>> wouldn't expect this to be classified as a P1 issue (I don't think the >>> w64-mingw32 toolchain is considered to be a primary target, is it?) >> >> Yeah, it's not getting fixed in 4.5. And no, we aren't even a >> secondary target :( >> >>> My frustration right now is that the GCC trunk has been in stage 4 since >>> December...aside from the fact that I would be wary personally of moving >>> to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for >>> these targets... >>> >>> After saying all that, the documentation about multilib should maybe have >>> some caveats... >> >> Well, to be fair, we never advertised that it even exists... so..... > > In both how-to-build docs, yes, you do :) > > I know that there was the "the tools now track gcc" statement and "no more > need to patch gcc." One of the problems really is going to be requiring the > use of the 4.6 trunk to get the correct behavior for installation of the > toolchain (multilib notwithstanding, I still feel the installation of the > target DLLs is also woefully incorrect, so I presume the patch mentioned above > does that as well) unless there are also plans to backport them to 4.5, which > I would doubt. I would never use the stage 1,2, or 3 trunks to build > production code (well, maybe the stage 3 depending on the issues in it)-- they > are just too unstable --which means I'll track the 4.5 branch for quite a > while. > > Don't know what I'll do...wait for the patch(es) to be applied, do the work > myself, or just deal with it (using nonmultilib, moving the files to where they > should be, and modifying the installed .la files correctly...) > > OK...vent mode off :) > Hi, here are the patches to make the dlls not clash, "v1.patch" for libtool, "gcc_multilib.patch" for gcc. The dlls are prefixed "w32" and "w64" respectively. You'll need to regenerate the gcc configury, particularly for the target support libs, after installing a patched version of libtool. I'm still waiting for the FSF paperwork to be done. |
From: Doug S. <dou...@gm...> - 2010-03-21 18:24:10
|
On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote: > 2010/3/21 Ozkan Sezer <se...@gm...>: > > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike <nig...@gm...> 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 <dou...@gm...> 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...) |
From: Kai T. <kti...@go...> - 2010-03-21 18:36:35
|
2010/3/21 Doug Semler <dou...@gm...>: > On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote: >> 2010/3/21 Ozkan Sezer <se...@gm...>: >> > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike <nig...@gm...> > 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 <dou...@gm...> > 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. Yes, ld is at the moment the app not supporting options for overriding underscore mode. The sad thing about ld is that is uses hardcoded values in script-templates instead of using the target default. By this issue in design it is much work to allow such an option. The last patches I did for this were stopped at the point (but patch is now in bfd) to have an bfd API to query undescoring mode by internal bfd-name. I didn't continued on this reasoned by lack of time. > 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). I think there is in general a good chance for this. And the necessary change for gcc 4.6 (which is pretty small one) I'll approve as soon as issue in binutils are solved. > 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...) Yeah, dlltool uses here gas to generate the import-library. IMHO it should support the same generation mechanism without gas (like ld), too. And this should get default. By this the initial idea is to move the import-library generation code into bfd's coff code. So we could avoid double implementation. Additionally it would allow to support in future the ANON-object file format version 0 (new import descriptor), too. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: NightStrike <nig...@gm...> - 2010-03-22 00:31:21
|
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <dou...@gm...> wrote: > On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: >> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> wrote: >> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The >> > target DLLs for things like libstdc++, etc are installed into the >> > completely wrong spot due to a -bindir parameter in the libtool portion >> > of the DLL makefiles. They are installed into the host's binary >> > directory (which makes no sense to me at all - by the way I use a >> > different -prefix and -exec-prefix), they cannot be overridden by the >> > --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden >> > and which I have working multilib with a minor patch to >> > gcc/config/t-cygming), nor do they obey the version specific runtime >> > libs directory like the native toolchain does. In addition, the >> > mulitlib install can clobber the dlls in that (wrong) bindir with the >> > wrong arch type (the 32bit install puts the 64 bit version there after >> > all is said and done). >> >> Jon Y has a patch for all of that. >> >> > Given that the trunk of GCC is in stage 4, I wouldn't expect any of this >> > to be fixed prior to the release even if patches were submitted since I >> > wouldn't expect this to be classified as a P1 issue (I don't think the >> > w64-mingw32 toolchain is considered to be a primary target, is it?) >> >> Yeah, it's not getting fixed in 4.5. And no, we aren't even a >> secondary target :( >> >> > My frustration right now is that the GCC trunk has been in stage 4 since >> > December...aside from the fact that I would be wary personally of moving >> > to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for >> > these targets... >> > >> > After saying all that, the documentation about multilib should maybe have >> > some caveats... >> >> Well, to be fair, we never advertised that it even exists... so..... > > In both how-to-build docs, yes, you do :) Oh... well, hmm.... We should probably change that. In my defense, I've been away for a while :) > I know that there was the "the tools now track gcc" statement and "no more > need to patch gcc." One of the problems really is going to be requiring the > use of the 4.6 trunk to get the correct behavior for installation of the > toolchain (multilib notwithstanding, I still feel the installation of the > target DLLs is also woefully incorrect, so I presume the patch mentioned above > does that as well) unless there are also plans to backport them to 4.5, which > I would doubt. I would never use the stage 1,2, or 3 trunks to build > production code (well, maybe the stage 3 depending on the issues in it)-- they > are just too unstable --which means I'll track the 4.5 branch for quite a > while. There's a few choices. Foremost, I would bribe Kai into getting this committed to 4.6 the moment it opens up into stage 1. That way, you are essentially using 4.5+patches, as opposed to somewhere in the middle of stage 1 4.6, which will have a lot more churn in the code. The best way to do that would be to have the binutils side already done. Beyond that... just grin and bear it? I dunno.. I'm open to suggestions. How do you want us to support you? > Don't know what I'll do...wait for the patch(es) to be applied, do the work > myself, or just deal with it (using nonmultilib, moving the files to where they > should be, and modifying the installed .la files correctly...) > > OK...vent mode off :) > |
From: Doug S. <dou...@gm...> - 2010-03-22 19:22:18
|
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike <nig...@gm...> wrote: > On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <dou...@gm...> wrote: >> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: >>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> wrote: >>> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The >>> > target DLLs for things like libstdc++, etc are installed into the >>> > completely wrong spot due to a -bindir parameter in the libtool portion >>> > of the DLL makefiles. They are installed into the host's binary >>> > directory (which makes no sense to me at all - by the way I use a >>> > different -prefix and -exec-prefix), they cannot be overridden by the >>> > --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden >>> > and which I have working multilib with a minor patch to >>> > gcc/config/t-cygming), nor do they obey the version specific runtime >>> > libs directory like the native toolchain does. In addition, the >>> > mulitlib install can clobber the dlls in that (wrong) bindir with the >>> > wrong arch type (the 32bit install puts the 64 bit version there after >>> > all is said and done). >>> >>> Jon Y has a patch for all of that. >>> >>> > Given that the trunk of GCC is in stage 4, I wouldn't expect any of this >>> > to be fixed prior to the release even if patches were submitted since I >>> > wouldn't expect this to be classified as a P1 issue (I don't think the >>> > w64-mingw32 toolchain is considered to be a primary target, is it?) >>> >>> Yeah, it's not getting fixed in 4.5. And no, we aren't even a >>> secondary target :( >>> >>> > My frustration right now is that the GCC trunk has been in stage 4 since >>> > December...aside from the fact that I would be wary personally of moving >>> > to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for >>> > these targets... >>> > >>> > After saying all that, the documentation about multilib should maybe have >>> > some caveats... >>> >>> Well, to be fair, we never advertised that it even exists... so..... >> >> In both how-to-build docs, yes, you do :) > > Oh... well, hmm.... We should probably change that. In my defense, > I've been away for a while :) > >> I know that there was the "the tools now track gcc" statement and "no more >> need to patch gcc." One of the problems really is going to be requiring the >> use of the 4.6 trunk to get the correct behavior for installation of the >> toolchain (multilib notwithstanding, I still feel the installation of the >> target DLLs is also woefully incorrect, so I presume the patch mentioned above >> does that as well) unless there are also plans to backport them to 4.5, which >> I would doubt. I would never use the stage 1,2, or 3 trunks to build >> production code (well, maybe the stage 3 depending on the issues in it)-- they >> are just too unstable --which means I'll track the 4.5 branch for quite a >> while. > > There's a few choices. Foremost, I would bribe Kai into getting this > committed to 4.6 the moment it opens up into stage 1. That way, you > are essentially using 4.5+patches, as opposed to somewhere in the > middle of stage 1 4.6, which will have a lot more churn in the code. > The best way to do that would be to have the binutils side already > done. > > Beyond that... just grin and bear it? I dunno.. I'm open to > suggestions. How do you want us to support you? > Oh, I don't need you to support me in particular...I'm a pretty smart guy :) ... I just don't like reinventing the wheel is all :) In fact I'd be willing to volunteer to help with issues like this (in what little free time I have that is) - at the least on discussing things and at the most suggesting ideas or submitting patches for discussion. I'm still waiting for FSF paperwork myself so that I can do things on the binutils side, and I'll probably do FSF paperwork on the gcc side as well so that anything I run into can be at least submitted for comment without problem.. The biggest thing right now is that there are three projects that are interlinked...a change in behavior in one may require a change in all three of binutils, gcc, and the runtime...and really, where do you discuss those changes, all three lists? Even something as seemingly small as the underscore stuff for x64 is something that cascades really quickly... For example, the underscore stuff: the binutils ld right now doesn't support turning it off without a patch, which means that import and export objects can't be built during link without the option (you get a bunch of 'cannot export' stuff) Even with the patch, gcc has the -fno-leading-underscore option, but if you build mingw x64 with the no leading underscores, you have to remember to build everything (from target libraries to your own code) from that point forward with that option, or you need to patch gcc to default to no leading underscore on 64 bit, which has its own set of problems. but that leads to: gcc will still not link 64 bit dlls correctly without being patched, because the entry point will no longer be correct in the spec file. In addition, there's still the matter of getting the --no-leading-underscores option to the (patched) binutils link command line correctly...which means that not only must -fno-leading-underscore be passed on the command line, but also -Wl,--no-leading-underscores... Which also leads to: how can gcc determine which way to go? If you, for example, have a linker that defaults to the no leading underscore method, you want to link with DllMainCrtStartup symbol. If you have a mingw toolchain that was built with -fno-leading-underscore, you also want this. In addition, if you want to change the default, you have to change the default in all of the tools in the chain at the same time. You can't use a binutils that defaults to no leading underscore in the same chain as a gcc or mingw that does, etc. For me, that's not a big deal, because I build the entire toolchain in one shot. However, since the three parts of the toolchain can be built and installed separately, it means ensuring that you match what is already installed...Then, there's the interoperability with code that has already been compiled (archives, import libraries, etc)...in order to link properly, the no leading underscore toolchain must be used to rebuild everything that you want to use. Which is why I'd like to see a default (even as a patch for 4.5) configure option available for all three parts of the toolchain (the same name of course so it can be used in a config.site file for example), so that the behavior of all three toolchains can default to one way or the other. You've already got the beginnings of it in the mingw part, and Kai has the patch for ld - so for that all that would be needed is a bfd/configure option that changes the TARGET_UNDERSCORE (and targ_underscore in config.bfd) behavior. GCC is slightly more problematic, but it's actually not too bad if you're not building multilib. Considering the fact that multilib builds are not necessarily working anyway, it can be hacked :) (sorry for being so long winded) |
From: NightStrike <nig...@gm...> - 2010-03-22 19:31:12
|
On Mon, Mar 22, 2010 at 3:22 PM, Doug Semler <dou...@gm...> wrote: > On Sun, Mar 21, 2010 at 8:31 PM, NightStrike <nig...@gm...> wrote: >> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <dou...@gm...> wrote: >>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: >>>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> wrote: >>>> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The >>>> > target DLLs for things like libstdc++, etc are installed into the >>>> > completely wrong spot due to a -bindir parameter in the libtool portion >>>> > of the DLL makefiles. They are installed into the host's binary >>>> > directory (which makes no sense to me at all - by the way I use a >>>> > different -prefix and -exec-prefix), they cannot be overridden by the >>>> > --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden >>>> > and which I have working multilib with a minor patch to >>>> > gcc/config/t-cygming), nor do they obey the version specific runtime >>>> > libs directory like the native toolchain does. In addition, the >>>> > mulitlib install can clobber the dlls in that (wrong) bindir with the >>>> > wrong arch type (the 32bit install puts the 64 bit version there after >>>> > all is said and done). >>>> >>>> Jon Y has a patch for all of that. >>>> >>>> > Given that the trunk of GCC is in stage 4, I wouldn't expect any of this >>>> > to be fixed prior to the release even if patches were submitted since I >>>> > wouldn't expect this to be classified as a P1 issue (I don't think the >>>> > w64-mingw32 toolchain is considered to be a primary target, is it?) >>>> >>>> Yeah, it's not getting fixed in 4.5. And no, we aren't even a >>>> secondary target :( >>>> >>>> > My frustration right now is that the GCC trunk has been in stage 4 since >>>> > December...aside from the fact that I would be wary personally of moving >>>> > to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for >>>> > these targets... >>>> > >>>> > After saying all that, the documentation about multilib should maybe have >>>> > some caveats... >>>> >>>> Well, to be fair, we never advertised that it even exists... so..... >>> >>> In both how-to-build docs, yes, you do :) >> >> Oh... well, hmm.... We should probably change that. In my defense, >> I've been away for a while :) >> >>> I know that there was the "the tools now track gcc" statement and "no more >>> need to patch gcc." One of the problems really is going to be requiring the >>> use of the 4.6 trunk to get the correct behavior for installation of the >>> toolchain (multilib notwithstanding, I still feel the installation of the >>> target DLLs is also woefully incorrect, so I presume the patch mentioned above >>> does that as well) unless there are also plans to backport them to 4.5, which >>> I would doubt. I would never use the stage 1,2, or 3 trunks to build >>> production code (well, maybe the stage 3 depending on the issues in it)-- they >>> are just too unstable --which means I'll track the 4.5 branch for quite a >>> while. >> >> There's a few choices. Foremost, I would bribe Kai into getting this >> committed to 4.6 the moment it opens up into stage 1. That way, you >> are essentially using 4.5+patches, as opposed to somewhere in the >> middle of stage 1 4.6, which will have a lot more churn in the code. >> The best way to do that would be to have the binutils side already >> done. >> >> Beyond that... just grin and bear it? I dunno.. I'm open to >> suggestions. How do you want us to support you? >> > > Oh, I don't need you to support me in particular...I'm a pretty smart > guy :) ... I just don't like reinventing the wheel is all :) > > In fact I'd be willing to volunteer to help with issues like this (in > what little free time I have that is) - at the least on discussing > things and at the most suggesting ideas or submitting patches for > discussion. I'm still waiting for FSF paperwork myself so that I can > do things on the binutils side, and I'll probably do FSF paperwork on > the gcc side as well so that anything I run into can be at least > submitted for comment without problem.. The biggest thing right now is > that there are three projects that are interlinked...a change in > behavior in one may require a change in all three of binutils, gcc, > and the runtime...and really, where do you discuss those changes, all > three lists? Even something as seemingly small as the underscore > stuff for x64 is something that cascades really quickly... > > For example, the underscore stuff: > the binutils ld right now doesn't support turning it off without a > patch, which means that import and export objects can't be built > during link without the option (you get a bunch of 'cannot export' > stuff) > Even with the patch, gcc has the -fno-leading-underscore option, but > if you build mingw x64 with the no leading underscores, you have to > remember to build everything (from target libraries to your own code) > from that point forward with that option, or you need to patch gcc to > default to no leading underscore on 64 bit, which has its own set of > problems. > but that leads to: gcc will still not link 64 bit dlls correctly > without being patched, because the entry point will no longer be > correct in the spec file. In addition, there's still the matter of > getting the --no-leading-underscores option to the (patched) binutils > link command line correctly...which means that not only must > -fno-leading-underscore be passed on the command line, but also > -Wl,--no-leading-underscores... > > Which also leads to: how can gcc determine which way to go? If you, > for example, have a linker that defaults to the no leading underscore > method, you want to link with DllMainCrtStartup symbol. If you have a > mingw toolchain that was built with -fno-leading-underscore, you also > want this. > > In addition, if you want to change the default, you have to change the > default in all of the tools in the chain at the same time. You can't > use a binutils that defaults to no leading underscore in the same > chain as a gcc or mingw that does, etc. For me, that's not a big > deal, because I build the entire toolchain in one shot. However, > since the three parts of the toolchain can be built and installed > separately, it means ensuring that you match what is already > installed...Then, there's the interoperability with code that has > already been compiled (archives, import libraries, etc)...in order to > link properly, the no leading underscore toolchain must be used to > rebuild everything that you want to use. > > Which is why I'd like to see a default (even as a patch for 4.5) > configure option available for all three parts of the toolchain (the > same name of course so it can be used in a config.site file for > example), so that the behavior of all three toolchains can default to > one way or the other. You've already got the beginnings of it in the > mingw part, and Kai has the patch for ld - so for that all that would > be needed is a bfd/configure option that changes the TARGET_UNDERSCORE > (and targ_underscore in config.bfd) behavior. GCC is slightly more > problematic, but it's actually not too bad if you're not building > multilib. Considering the fact that multilib builds are not > necessarily working anyway, it can be hacked :) > > (sorry for being so long winded) > These are reasons that I would much prefer to force whoever we have to to accept a patch to gcc 4.5 before it's released. There will be a large time gap between 4.5 and 4.6, and it will be painful to maintain things going forward. We should REALLY try to get this into 4.5. |
From: Kai T. <kti...@go...> - 2010-03-22 19:39:31
|
2010/3/22 Doug Semler <dou...@gm...>: > On Sun, Mar 21, 2010 at 8:31 PM, NightStrike <nig...@gm...> wrote: >> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <dou...@gm...> wrote: >>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: >>>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> wrote: >>>> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The >>>> > target DLLs for things like libstdc++, etc are installed into the >>>> > completely wrong spot due to a -bindir parameter in the libtool portion >>>> > of the DLL makefiles. They are installed into the host's binary >>>> > directory (which makes no sense to me at all - by the way I use a >>>> > different -prefix and -exec-prefix), they cannot be overridden by the >>>> > --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden >>>> > and which I have working multilib with a minor patch to >>>> > gcc/config/t-cygming), nor do they obey the version specific runtime >>>> > libs directory like the native toolchain does. In addition, the >>>> > mulitlib install can clobber the dlls in that (wrong) bindir with the >>>> > wrong arch type (the 32bit install puts the 64 bit version there after >>>> > all is said and done). >>>> >>>> Jon Y has a patch for all of that. >>>> >>>> > Given that the trunk of GCC is in stage 4, I wouldn't expect any of this >>>> > to be fixed prior to the release even if patches were submitted since I >>>> > wouldn't expect this to be classified as a P1 issue (I don't think the >>>> > w64-mingw32 toolchain is considered to be a primary target, is it?) >>>> >>>> Yeah, it's not getting fixed in 4.5. And no, we aren't even a >>>> secondary target :( >>>> >>>> > My frustration right now is that the GCC trunk has been in stage 4 since >>>> > December...aside from the fact that I would be wary personally of moving >>>> > to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for >>>> > these targets... >>>> > >>>> > After saying all that, the documentation about multilib should maybe have >>>> > some caveats... >>>> >>>> Well, to be fair, we never advertised that it even exists... so..... >>> >>> In both how-to-build docs, yes, you do :) >> >> Oh... well, hmm.... We should probably change that. In my defense, >> I've been away for a while :) >> >>> I know that there was the "the tools now track gcc" statement and "no more >>> need to patch gcc." One of the problems really is going to be requiring the >>> use of the 4.6 trunk to get the correct behavior for installation of the >>> toolchain (multilib notwithstanding, I still feel the installation of the >>> target DLLs is also woefully incorrect, so I presume the patch mentioned above >>> does that as well) unless there are also plans to backport them to 4.5, which >>> I would doubt. I would never use the stage 1,2, or 3 trunks to build >>> production code (well, maybe the stage 3 depending on the issues in it)-- they >>> are just too unstable --which means I'll track the 4.5 branch for quite a >>> while. >> >> There's a few choices. Foremost, I would bribe Kai into getting this >> committed to 4.6 the moment it opens up into stage 1. That way, you >> are essentially using 4.5+patches, as opposed to somewhere in the >> middle of stage 1 4.6, which will have a lot more churn in the code. >> The best way to do that would be to have the binutils side already >> done. >> >> Beyond that... just grin and bear it? I dunno.. I'm open to >> suggestions. How do you want us to support you? >> > > Oh, I don't need you to support me in particular...I'm a pretty smart > guy :) ... I just don't like reinventing the wheel is all :) > > In fact I'd be willing to volunteer to help with issues like this (in > what little free time I have that is) - at the least on discussing > things and at the most suggesting ideas or submitting patches for > discussion. I'm still waiting for FSF paperwork myself so that I can > do things on the binutils side, and I'll probably do FSF paperwork on > the gcc side as well so that anything I run into can be at least > submitted for comment without problem.. The biggest thing right now is > that there are three projects that are interlinked...a change in > behavior in one may require a change in all three of binutils, gcc, > and the runtime...and really, where do you discuss those changes, all > three lists? Even something as seemingly small as the underscore > stuff for x64 is something that cascades really quickly... You help is welcome and appreciated. The synchronization between all three ventures (cygwin, mingw.org, and mingw-w64) is a bit exertive but in general not that problematic. Danny, Dave, and I do coordinate us. But I agree that there are some venture-specific needs, which lead us to introduce the -w64- venture key-part in configure, so that we can support additional features the other ventures don't support, or aren't interested in. > For example, the underscore stuff: > the binutils ld right now doesn't support turning it off without a > patch, which means that import and export objects can't be built > during link without the option (you get a bunch of 'cannot export' > stuff) > Even with the patch, gcc has the -fno-leading-underscore option, but > if you build mingw x64 with the no leading underscores, you have to > remember to build everything (from target libraries to your own code) > from that point forward with that option, or you need to patch gcc to > default to no leading underscore on 64 bit, which has its own set of > problems. > but that leads to: gcc will still not link 64 bit dlls correctly > without being patched, because the entry point will no longer be > correct in the spec file. In addition, there's still the matter of > getting the --no-leading-underscores option to the (patched) binutils > link command line correctly...which means that not only must > -fno-leading-underscore be passed on the command line, but also > -Wl,--no-leading-underscores... > > Which also leads to: how can gcc determine which way to go? If you, > for example, have a linker that defaults to the no leading underscore > method, you want to link with DllMainCrtStartup symbol. If you have a > mingw toolchain that was built with -fno-leading-underscore, you also > want this. Well, in fact is this entry-point a no issue. By a recent patch, ld is able to select the proper entry-point without the need of specifying the -e <entry>. So this argument is in fact deprecated. Major pain here is the backward-compatibility necessary for older binutils. Buf for 4.6 I would prefer to make a crued break in support of older binutils versions (at least if configure for using no-underscore variant). > In addition, if you want to change the default, you have to change the > default in all of the tools in the chain at the same time. You can't > use a binutils that defaults to no leading underscore in the same > chain as a gcc or mingw that does, etc. For me, that's not a big > deal, because I build the entire toolchain in one shot. However, > since the three parts of the toolchain can be built and installed > separately, it means ensuring that you match what is already > installed...Then, there's the interoperability with code that has > already been compiled (archives, import libraries, etc)...in order to > link properly, the no leading underscore toolchain must be used to > rebuild everything that you want to use. Yes, this is required for having real support of w64 ABI. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Doug S. <dou...@gm...> - 2010-03-22 21:07:34
|
On Mon, Mar 22, 2010 at 3:39 PM, Kai Tietz <kti...@go...> wrote: > 2010/3/22 Doug Semler <dou...@gm...>: >> On Sun, Mar 21, 2010 at 8:31 PM, NightStrike <nig...@gm...> wrote: >>> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <dou...@gm...> wrote: > > Well, in fact is this entry-point a no issue. By a recent patch, ld is > able to select the proper entry-point without the need of specifying > the -e <entry>. So this argument is in fact deprecated. Major pain > here is the backward-compatibility necessary for older binutils. Buf > for 4.6 I would prefer to make a crued break in support of older > binutils versions (at least if configure for using no-underscore > variant). > In light of that - the patch for ld --no-leading-underscores doesn't work if you don't patch gcc to handle that...because the linker will select default entry of 1000 because it isn't able to find _DllMainCRTStartup@12 that is passed by gcc as the desired entry point. I guess the logic for the entry point in the linker could be looked at though... |