From: Earnie <ea...@us...> - 2011-11-17 19:03:23
|
I've been trying to debug why when building as a DLL with gcc-4.6.1 and binutils-2.21.53.20110804 the libxml2-2.7.8 xmlcatalog was failing to parse the catalogs delivered in its tests. The issue is an array table of 256 char values of 0x00 or 0x01 that defines if a character is XML valid. The data in that array is all 0x00 instead of having 0x01 in the valid character values. This table resides in the DLL and has been properly exported and imported by the programs using it. After much ado I've found that modifying the optimization from -O2 to -O0 caused the data values to be correct. I tried creating a simple test but of course it doesn't fail like it does with libxml2-2.7.8. Anyone have any suggestions? I've already tried -O1 which produced the same results as -O2. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Greg C. <gch...@sb...> - 2011-11-17 19:37:18
|
On 2011-11-17 19:03Z, Earnie wrote: > I've been trying to debug why when building as a DLL with gcc-4.6.1 and > binutils-2.21.53.20110804 the libxml2-2.7.8 xmlcatalog was failing to > parse the catalogs delivered in its tests. The issue is an array table > of 256 char values of 0x00 or 0x01 that defines if a character is XML > valid. The data in that array is all 0x00 instead of having 0x01 in the > valid character values. This table resides in the DLL and has been > properly exported and imported by the programs using it. After much ado > I've found that modifying the optimization from -O2 to -O0 caused the > data values to be correct. I tried creating a simple test but of course > it doesn't fail like it does with libxml2-2.7.8. > > Anyone have any suggestions? I've already tried -O1 which produced the > same results as -O2. I don't know how to make it "just work", but... 0) I'm sure you've googled the xm...@gn... mailing list already. 1) Experiment with earlier versions of gcc and libxml. I know I can build libxml2-2.6.26 with MinGW gcc-3.4.5, for example. Maybe this gets you to a working version of libxml that's sufficiently modern to meet your requirements; at least it's a path to narrowing down where the problem arose. 2) Experiment with spelling out the specific suboptions that are turned on by '-O1': http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html Maybe there's a particular one that causes the problem and can be selectively turned off without losing too much speed. 3) Modify the source. If the array is const, try making it nonconst. Or try wrapping it in a function: I've always preferred exporting and importing functions rather than data (at least at one historical point that was more robust), and you can use #pragma GCC optimize on a function. |
From: Earnie <ea...@us...> - 2011-11-17 20:17:19
|
Greg Chicares wrote: > On 2011-11-17 19:03Z, Earnie wrote: >> I've been trying to debug why when building as a DLL with gcc-4.6.1 and >> binutils-2.21.53.20110804 the libxml2-2.7.8 xmlcatalog was failing to >> parse the catalogs delivered in its tests. The issue is an array table >> of 256 char values of 0x00 or 0x01 that defines if a character is XML >> valid. The data in that array is all 0x00 instead of having 0x01 in the >> valid character values. This table resides in the DLL and has been >> properly exported and imported by the programs using it. After much ado >> I've found that modifying the optimization from -O2 to -O0 caused the >> data values to be correct. I tried creating a simple test but of course >> it doesn't fail like it does with libxml2-2.7.8. >> >> Anyone have any suggestions? I've already tried -O1 which produced the >> same results as -O2. > > I don't know how to make it "just work", but... > > 0) I'm sure you've googled the xm...@gn... mailing list already. > > 1) Experiment with earlier versions of gcc and libxml. I know I can > build libxml2-2.6.26 with MinGW gcc-3.4.5, for example. Maybe this > gets you to a working version of libxml that's sufficiently modern > to meet your requirements; at least it's a path to narrowing down > where the problem arose. > I'm interested in what works with the currently delivered by mingw-get and that currently is gcc-4.6.1. I'm not interested in a workaround that includes using older software. Now narrowing the path to find which version caused the issue to track back to the commit I can understand but in the meantime what options do I have with 4.6.1? > 2) Experiment with spelling out the specific suboptions that are > turned on by '-O1': > http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > Maybe there's a particular one that causes the problem and can be > selectively turned off without losing too much speed. > Yes, I plan to attempt this but after coming up with a minimal test that fails. In other words what else in the code caused the array data to be 0x00 for 256 items that didn't cause my already minimal test an issue. > 3) Modify the source. If the array is const, try making it nonconst. > Or try wrapping it in a function: I've always preferred exporting > and importing functions rather than data (at least at one historical > point that was more robust), and you can use #pragma GCC optimize > on a function. Well, modifying the source to print out the array was how I found the values. :) I thought about using a function instead of the macro used now. But well, it should just work anyway with the data. Thanks for you hints, it is appreciated. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Earnie <ea...@us...> - 2011-11-17 21:29:56
|
Earnie wrote: >> 2) Experiment with spelling out the specific suboptions that are >> turned on by '-O1': >> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html >> Maybe there's a particular one that causes the problem and can be >> selectively turned off without losing too much speed. >> > > Yes, I plan to attempt this but after coming up with a minimal test that > fails. In other words what else in the code caused the array data to be > 0x00 for 256 items that didn't cause my already minimal test an issue. > And of course adding the flags manually as documented[1] for -O1 doesn't present the issue. So what happens in an undocumented manner? Is there a way to determine that? [1]http://bit.ly/sF1UdC -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Charles W. <cwi...@us...> - 2011-11-17 21:36:10
|
On 11/17/2011 3:17 PM, Earnie wrote: > I'm interested in what works with the currently delivered by mingw-get > and that currently is gcc-4.6.1. I'm not interested in a workaround > that includes using older software. Now narrowing the path to find > which version caused the issue to track back to the commit I can > understand but in the meantime what options do I have with 4.6.1? BTW, I think there have been a few bugs fixed recently in binutils that may affect PE/COFF binaries (I forget the details, but one such fix prompted a re-release of cygwin gcc IIRC). Maybe we need to update mingw32-binutils? -- Chuck |
From: Chris S. <ir0...@gm...> - 2011-11-17 23:15:56
|
On 17 November 2011 16:36, Charles Wilson wrote: > On 11/17/2011 3:17 PM, Earnie wrote: >> I'm interested in what works with the currently delivered by mingw-get >> and that currently is gcc-4.6.1. I'm not interested in a workaround >> that includes using older software. Now narrowing the path to find >> which version caused the issue to track back to the commit I can >> understand but in the meantime what options do I have with 4.6.1? > > BTW, I think there have been a few bugs fixed recently in binutils that > may affect PE/COFF binaries (I forget the details, but one such fix > prompted a re-release of cygwin gcc IIRC). Maybe we need to update > mingw32-binutils? I believe Tristan plans on making a 2.22 release next week, so I was planning on waiting until then. That should contain DaveK's fix I believe. Earnie, there has also been some back and forth regarding gcc optimizations and the MinGW gcc with respect to building GDB. I'm not sure if it's related, but if you build with '-fno-omit-frame-pointer' does it help? Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie <ea...@us...> - 2011-11-18 13:37:03
|
Chris Sutcliffe wrote: > Earnie, there has also been some back and forth regarding gcc > optimizations and the MinGW gcc with respect to building GDB. I'm not > sure if it's related, but if you build with '-fno-omit-frame-pointer' > does it help? I added -fomit-frame-pointer when I did the individual list that is documented for -O1 to contain with no issue. There is definitely a difference by adding -O1, the objdump -Ss object file source comparison gives different assembler in the code. I'll give the -fno-omit-frame-pointer a try with -O1 to see if it makes a difference. I'll also add a -save-temps switch and compare those files. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Earnie <ea...@us...> - 2011-11-18 15:04:07
Attachments:
chvalid.s-with-O.txt
chvalid.s-without-O.txt
|
Earnie wrote: > Chris Sutcliffe wrote: >> Earnie, there has also been some back and forth regarding gcc >> optimizations and the MinGW gcc with respect to building GDB. I'm not >> sure if it's related, but if you build with '-fno-omit-frame-pointer' >> does it help? > > I added -fomit-frame-pointer when I did the individual list that is > documented for -O1 to contain with no issue. There is definitely a > difference by adding -O1, the objdump -Ss object file source comparison > gives different assembler in the code. I'll give the > -fno-omit-frame-pointer a try with -O1 to see if it makes a difference. > I'll also add a -save-temps switch and compare those files. > -fno-omit-frame-pointer did not help. The attached files show the assembler difference between what is documented as enabled by -O1 specified individually and adding -O1. Notice the difference for xmlIsPubidChar_tab. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Greg C. <gch...@sb...> - 2011-11-18 16:06:34
|
On 2011-11-18 15:03Z, Earnie wrote: [... > The attached files show the assembler difference between what is > documented as enabled by -O1 specified individually and adding -O1. > Notice the difference for xmlIsPubidChar_tab. In these source files (which I guess might match yours) respectively: http://doxygen.reactos.org/da/d9c/chvalid_8h_source.html http://doxygen.reactos.org/d8/d54/chvalid_8c_source.html I see: XMLPUBVAR const unsigned char xmlIsPubidChar_tab[256]; const unsigned char xmlIsPubidChar_tab[256] = { so I gather that there's an export-import decoration only on the declaration, not on the definition. A shot in the dark: does it do what you want if you decorate the definition too? It's been years since I messed with this stuff, but I seem to recall that some compilers wanted both to be decorated. I know that's not the "solution" you want, but it might point to a regression in the MinGW toolchain and possibly even produce a nice minimal testcase. Well, like I said, it's just a shot in the dark. |
From: Earnie <ea...@us...> - 2011-11-18 16:24:10
|
Greg Chicares wrote: > On 2011-11-18 15:03Z, Earnie wrote: > [... >> The attached files show the assembler difference between what is >> documented as enabled by -O1 specified individually and adding -O1. >> Notice the difference for xmlIsPubidChar_tab. > > In these source files (which I guess might match yours) respectively: > http://doxygen.reactos.org/da/d9c/chvalid_8h_source.html > http://doxygen.reactos.org/d8/d54/chvalid_8c_source.html > I see: > XMLPUBVAR const unsigned char xmlIsPubidChar_tab[256]; > const unsigned char xmlIsPubidChar_tab[256] = { > so I gather that there's an export-import decoration only on the > declaration, not on the definition. A shot in the dark: does it do > what you want if you decorate the definition too? It's been years Tried that already, no it doesn't matter. > since I messed with this stuff, but I seem to recall that some > compilers wanted both to be decorated. I know that's not the Yea, that is what I thought to but my minimal test works either way. > "solution" you want, but it might point to a regression in the > MinGW toolchain and possibly even produce a nice minimal testcase. > Well, like I said, it's just a shot in the dark. But it would have been simple enough to convince the maintainers to the patch. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Kai T. <kti...@go...> - 2011-11-18 16:33:13
|
2011/11/18 Earnie <ea...@us...>: > Greg Chicares wrote: >> On 2011-11-18 15:03Z, Earnie wrote: >> [... >>> The attached files show the assembler difference between what is >>> documented as enabled by -O1 specified individually and adding -O1. >>> Notice the difference for xmlIsPubidChar_tab. >> >> In these source files (which I guess might match yours) respectively: >> http://doxygen.reactos.org/da/d9c/chvalid_8h_source.html >> http://doxygen.reactos.org/d8/d54/chvalid_8c_source.html >> I see: >> XMLPUBVAR const unsigned char xmlIsPubidChar_tab[256]; >> const unsigned char xmlIsPubidChar_tab[256] = { >> so I gather that there's an export-import decoration only on the >> declaration, not on the definition. A shot in the dark: does it do >> what you want if you decorate the definition too? It's been years > > Tried that already, no it doesn't matter. > >> since I messed with this stuff, but I seem to recall that some >> compilers wanted both to be decorated. I know that's not the > > Yea, that is what I thought to but my minimal test works either way. > >> "solution" you want, but it might point to a regression in the >> MinGW toolchain and possibly even produce a nice minimal testcase. >> Well, like I said, it's just a shot in the dark. > > But it would have been simple enough to convince the maintainers to the > patch. > > -- > Earnie > -- https://sites.google.com/site/earnieboyd/ On a first glance I would see the issue in definition of XMLPUBVAR. For dll-version build it gets defined to '__declspec(dllexport)'. So the declaration in header for the variable becomes a definition itself, as here no 'extern' is provided. And this doesn't seem to be a compiler bug AFAICS. Kai |
From: Earnie <ea...@us...> - 2011-11-18 16:54:21
|
Kai Tietz wrote: > 2011/11/18 Earnie <ea...@us...>: >> Greg Chicares wrote: >>> On 2011-11-18 15:03Z, Earnie wrote: >>> [... >>>> The attached files show the assembler difference between what is >>>> documented as enabled by -O1 specified individually and adding -O1. >>>> Notice the difference for xmlIsPubidChar_tab. >>> >>> In these source files (which I guess might match yours) respectively: >>> http://doxygen.reactos.org/da/d9c/chvalid_8h_source.html >>> http://doxygen.reactos.org/d8/d54/chvalid_8c_source.html >>> I see: >>> XMLPUBVAR const unsigned char xmlIsPubidChar_tab[256]; >>> const unsigned char xmlIsPubidChar_tab[256] = { >>> so I gather that there's an export-import decoration only on the >>> declaration, not on the definition. A shot in the dark: does it do >>> what you want if you decorate the definition too? It's been years >> >> Tried that already, no it doesn't matter. >> >>> since I messed with this stuff, but I seem to recall that some >>> compilers wanted both to be decorated. I know that's not the >> >> Yea, that is what I thought to but my minimal test works either way. >> >>> "solution" you want, but it might point to a regression in the >>> MinGW toolchain and possibly even produce a nice minimal testcase. >>> Well, like I said, it's just a shot in the dark. >> >> But it would have been simple enough to convince the maintainers to the >> patch. >> > > On a first glance I would see the issue in definition of XMLPUBVAR. > For dll-version build it gets defined to '__declspec(dllexport)'. So > the declaration in header for the variable becomes a definition > itself, as here no 'extern' is provided. > > And this doesn't seem to be a compiler bug AFAICS. > I ensured that the calling program does indeed '__declspec(dllimport) extern' the data. The point here is the program works if -O0 is used instead of -O1. The files I attached earlier, which are pointed to by Greg, are the files involved with exporting the data from the DLL and show the difference when I specify the optimization flags that are documented in GCC docs for -O1 versus specifying -O1. One would think that the two generated assembler files should be somewhat more identical, especially with the assembler calls, and they are not. Something else is happening when specifying -O1. XMLPUBVAR is defined as '__declspec(dllexport)' when IN_LIBXML is defined and is defined as '__declspec(dllimport) extern' when it is not defined. IN_LIBXML is defined explicitly in the source files that create the DLL. The using programs do not define IN_LIBXML. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Kai T. <kti...@go...> - 2011-11-18 17:11:27
|
2011/11/18 Earnie <ea...@us...>: > XMLPUBVAR is defined as '__declspec(dllexport)' when IN_LIBXML is > defined and is defined as '__declspec(dllimport) extern' when it is not > defined. IN_LIBXML is defined explicitly in the source files that create > the DLL. The using programs do not define IN_LIBXML. Correct, this is exactly the issue. The issue caused by the DLL itself, not by the user. As each time this header gets included by the build of the DLL, as much TUs have their own variable (and an empty one). This would at least would be a cause why you are seeing here an empty variable. But well, maybe there is another issue too in this library. It would be interesting to see the export-table of the libxml DLL itself. Is there only one export and where it gets bound? To data or to bss? > -- > Earnie Kai |
From: Earnie <ea...@us...> - 2011-11-18 19:35:56
|
Kai Tietz wrote: > 2011/11/18 Earnie <ea...@us...>: >> XMLPUBVAR is defined as '__declspec(dllexport)' when IN_LIBXML is >> defined and is defined as '__declspec(dllimport) extern' when it is not >> defined. IN_LIBXML is defined explicitly in the source files that create >> the DLL. The using programs do not define IN_LIBXML. > > Correct, this is exactly the issue. The issue caused by the DLL > itself, not by the user. As each time this header gets included by > the build of the DLL, as much TUs have their own variable (and an > empty one). This would at least would be a cause why you are seeing > here an empty variable. But well, maybe there is another issue too in > this library. > So doing: #define XMLPUBVAR __declspec(dllexport) extern corrects not only this issue but also removes a warning for another variable. > It would be interesting to see the export-table of the libxml DLL > itself. Is there only one export and where it gets bound? To data or > to bss? > How do I determine that? Thanks Kai for persisting with this; now I'll be able to provide libxml with a simple patch. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Kai T. <kti...@go...> - 2011-11-18 20:39:23
|
2011/11/18 Earnie <ea...@us...>: > Kai Tietz wrote: >> 2011/11/18 Earnie <ea...@us...>: >>> XMLPUBVAR is defined as '__declspec(dllexport)' when IN_LIBXML is >>> defined and is defined as '__declspec(dllimport) extern' when it is not >>> defined. IN_LIBXML is defined explicitly in the source files that create >>> the DLL. The using programs do not define IN_LIBXML. >> >> Correct, this is exactly the issue. The issue caused by the DLL >> itself, not by the user. As each time this header gets included by >> the build of the DLL, as much TUs have their own variable (and an >> empty one). This would at least would be a cause why you are seeing >> here an empty variable. But well, maybe there is another issue too in >> this library. >> > > So doing: > > #define XMLPUBVAR __declspec(dllexport) extern > > corrects not only this issue but also removes a warning for another > variable. > >> It would be interesting to see the export-table of the libxml DLL >> itself. Is there only one export and where it gets bound? To data or >> to bss? >> > > How do I determine that? Well, you can look into dump of 'objdump -x' for this DLL and see the RVA-export for this export. Then look up section-table in this dump within what range this RVA is. It is a bit copious, but well ... > Thanks Kai for persisting with this; now I'll > be able to provide libxml with a simple patch. np > -- > Earnie > -- https://sites.google.com/site/earnieboyd/ Kai |
From: Roumen P. <bug...@ro...> - 2011-11-20 15:20:57
|
Hello Kai, Kai Tietz wrote: > 2011/11/18 Earnie<ear...@pu...>: >> Kai Tietz wrote: >>> 2011/11/18 Earnie<ear...@pu...>: [SNIP] > Well, you can look into dump of 'objdump -x' for this DLL and see the > RVA-export for this export. Then look up section-table in this dump > within what range this RVA is. It is a bit copious, but well ... May I ask for confirmation a) command "$ ....objdump -x .libs/libxml2-2.dll" report following .... [ 523] xmlIsPubidChar_tab .... Sections: .... 2 .rdata 00025984 7101b000 7101b000 000d9800 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA .... [4475](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00024720 _xmlIsPubidChar_tab .... b) Next command "objdump -D -j .rdata .libs/libxml2-2.dll" report .libs/libxml2-2.dll: file format pei-i386 .... Disassembly of section .rdata: .... 7103f720 <_xmlIsPubidChar_tab>: ... 7103f728: 00 00 add %al,(%eax) 7103f72a: 01 00 add %eax,(%eax) 7103f72c: 00 01 add %al,(%ecx) ... 7103f73e: 00 00 add %al,(%eax) .... Also : 0x7101b000 + 0x00024720 = 0x7103f720 c) quote for source code "chvalid.c": .... const unsigned char xmlIsPubidChar_tab[256] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, .... Kay, would you confirm that this build is not impacted by Earnie's report ? Roumen P.S. libxml2, current repository version, cross-environment build with gcc 4.4.0, binutils 2.19.1, CFLAGS="-O2 -fno-strict-aliasing -Wall" |
From: Earnie <ea...@us...> - 2011-11-20 16:11:04
|
Roumen Petrov wrote: > Hello Kai, > > Kai Tietz wrote: >> 2011/11/18 Earnie<ear...@pu...>: >>> Kai Tietz wrote: >>>> 2011/11/18 Earnie<ear...@pu...>: > [SNIP] > >> Well, you can look into dump of 'objdump -x' for this DLL and see the >> RVA-export for this export. Then look up section-table in this dump >> within what range this RVA is. It is a bit copious, but well ... > > May I ask for confirmation > a) command "$ ....objdump -x .libs/libxml2-2.dll" report following Later this week, or maybe have to be next week with Holiday coming up. > P.S. libxml2, current repository version, cross-environment build with > gcc 4.4.0, binutils 2.19.1, CFLAGS="-O2 -fno-strict-aliasing -Wall" Does your cross build use dwarf2 or sjlj? The mingw.org distribution delivers with --disable-sjlj-exceptions --with-dwarf2. Also does your cross build use DLL or static libraries? If I --disable-shared and --enable-static during the configure there is no issue either. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: richard <ri...@rv...> - 2011-11-20 17:17:06
|
Earnie schrieb: > Roumen Petrov wrote: > >> Hello Kai, >> >> Kai Tietz wrote: >> >>> 2011/11/18 Earnie<ear...@pu...>: >>> >>>> Kai Tietz wrote: >>>> >>>>> 2011/11/18 Earnie<ear...@pu...>: >>>>> >> [SNIP] >> >> >>> Well, you can look into dump of 'objdump -x' for this DLL and see the >>> RVA-export for this export. Then look up section-table in this dump >>> within what range this RVA is. It is a bit copious, but well ... >>> >> May I ask for confirmation >> a) command "$ ....objdump -x .libs/libxml2-2.dll" report following >> > Later this week, or maybe have to be next week with Holiday coming up. > > >> P.S. libxml2, current repository version, cross-environment build with >> gcc 4.4.0, binutils 2.19.1, CFLAGS="-O2 -fno-strict-aliasing -Wall" >> > Does your cross build use dwarf2 or sjlj? The mingw.org distribution > delivers with --disable-sjlj-exceptions --with-dwarf2. Also does your > cross build use DLL or static libraries? If I --disable-shared and > --enable-static during the configure there is no issue either. > > Hi, i am redling hear since a while. And i'am with xml am doing. I could need libxml2-2.7.8 compiled for XP and Vista as "dll". If this thread ist finisht, could someone send me this to my e-mal. thanks, sorry for my english language richard |
From: Roumen P. <bug...@ro...> - 2011-11-20 18:01:25
|
Earnie wrote: > Roumen Petrov wrote: [SNIP] > Does your cross build use dwarf2 or sjlj? The mingw.org distribution > delivers with --disable-sjlj-exceptions --with-dwarf2. Also does your > cross build use DLL or static libraries? If I --disable-shared and > --enable-static during the configure there is no issue either. > exact flags as script from gcc-4.4.0-mingw32-src-2.tar.gz Roumen |
From: Earnie <ea...@us...> - 2011-11-20 15:18:56
|
Earnie wrote: > Kai Tietz wrote: >> 2011/11/18 Earnie <ea...@us...>: >>> XMLPUBVAR is defined as '__declspec(dllexport)' when IN_LIBXML is >>> defined and is defined as '__declspec(dllimport) extern' when it is not >>> defined. IN_LIBXML is defined explicitly in the source files that create >>> the DLL. The using programs do not define IN_LIBXML. >> >> Correct, this is exactly the issue. The issue caused by the DLL >> itself, not by the user. As each time this header gets included by >> the build of the DLL, as much TUs have their own variable (and an >> empty one). This would at least would be a cause why you are seeing >> here an empty variable. But well, maybe there is another issue too in >> this library. >> > > So doing: > > #define XMLPUBVAR __declspec(dllexport) extern > > corrects not only this issue but also removes a warning for another > variable. > Can someone who has Cygwin installed tell me if this issue exists for Cygwin gcc-4.6.1? If so does this fix resolve the issue? Thanks, -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Charles W. <cwi...@us...> - 2011-11-20 20:18:11
|
On 11/20/2011 10:18 AM, Earnie wrote: > Can someone who has Cygwin installed tell me if this issue exists for > Cygwin gcc-4.6.1? If so does this fix resolve the issue? I can try later this evening if necessary -- but only with cygwin gcc-4.5.3. Dave has not yet uploaded any cygwin 4.6.x version, not even as a test release. So...if 4.5.3 is ok, I can test that -- but if you really need verification with 4.6.x on cygwin...then maybe Dave has a version he's working on -- but I don't plan on building a cygwin 4.6.x toolchain from scratch just to test a one-liner change in libxml! -- Chuck |
From: Roumen P. <bug...@ro...> - 2011-11-20 16:10:29
|
Hi Chuck, Charles Wilson wrote: > On 11/17/2011 3:17 PM, Earnie wrote: [SNIP] > BTW, I think there have been a few bugs fixed recently in binutils that > may affect PE/COFF binaries (I forget the details, but one such fix > prompted a re-release of cygwin gcc IIRC). Maybe we need to update > mingw32-binutils? > > -- > Chuck The solution "append extern" solve the reported mingw issue. Did you have cygwin build environment? If so could you test as extern is omited too for cygwin compiler in .../xmlexports.h ------------------- /* Cygwin platform, GNU compiler */ #if defined(_WIN32) && defined(__CYGWIN__) ... #define XMLPUBVAR __declspec(dllexport) ... ------------------- May be extern must be added in this place similarly as for mingw ? Roumen |
From: Charles W. <cwi...@us...> - 2011-11-20 20:27:52
|
On 11/20/2011 9:57 AM, Roumen Petrov wrote: > The solution "append extern" solve the reported mingw issue. > > Did you have cygwin build environment? If so could you test as extern is > omited too for cygwin compiler in .../xmlexports.h > > May be extern must be added in this place similarly as for mingw ? See my earlier reply. Would testing with cygwin gcc 4.5.3 be useful, or are we only concerned with behavior under gcc 4.6.x? -- Chuck |
From: Fabian G. <fa...@gr...> - 2011-11-18 15:52:05
|
Am 18.11.2011 14:36, schrieb Earnie: > I added -fomit-frame-pointer when I did the individual list that is > documented for -O1 to contain with no issue. There is definitely a Hm, how about "-fno-toplevel-reorder"? |
From: Earnie <ea...@us...> - 2011-11-18 16:41:58
|
Fabian Greffrath wrote: > Am 18.11.2011 14:36, schrieb Earnie: >> I added -fomit-frame-pointer when I did the individual list that is >> documented for -O1 to contain with no issue. There is definitely a > > Hm, how about "-fno-toplevel-reorder"? > It's not listed in the list for -O1 but trying it did not help. http://bit.ly/sF1UdC -- Earnie -- https://sites.google.com/site/earnieboyd/ |