From: Roumen P. <bug...@ro...> - 2012-01-22 17:06:57
|
Hello, Kai Tietz wrote: > 2011/11/21 Roumen Petrov<bugtrack-gwL0h148qh9RbBO/Cq/ER2...@pu...>: >> Hi Chuck, >> >> Charles Wilson wrote: >>> 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! >>> >> >> Earnie report issue with 4.6x mingw target. I guess that cygwin test with 4.5.3 will pass. >> >> It is one line change for mingw but not for cygwin. >> a) it is a regression in gcc => so it will be fixed and libxml could >> left as is for both host mingw* and cygwin. >> b) gcc 4.6+ correct one long standing bug => libxml has to be fixed for >> mingw* and cygwin hosts and libxslt has to be fixed for cygwin . Also >> did gcc 4.6+ announce that exported variables has to be defined as >> extern in addtion to dllexport specification ? >> >> Note that libxml work fine since I use it before mingw.org to announce >> gcc 4+ . >> >>> -- >>> Chuck >>> >> Roumen > > Roumen, > > this is a long standing bug in libxml. That older gcc are producing > here a working DLL is just by chance. Even for Windows targets it > makes a difference if you are doing a forwarder-declaration for > variables via 'extern' symbol, or if you don't. The attribute > dllexport never had intentional semantics of being a 'extern'. > Btw this same patch is for distributions like Fedora there already for > a long time. I am curious that this fix never was sent upstream. So > b) is the correct answer. > > Kai I would like to disagree as this is an optimization issue, i.e. compiler bug. All is fine: a) without optimization b) "-O1 -fno-tree-ccp -fno-tree-fre", or c) "-O2 -fno-tree-ccp -fno-tree-fre -fno-tree-pre" Optimization level three is same as two. Tested with cross-compiler: i686-mingw32-gcc -v --------------- Using built-in specs. COLLECT_GCC=<PREFIX>/bin/i686-mingw32-gcc COLLECT_LTO_WRAPPER=<PREFIX>/bin/../libexec/gcc/i686-mingw32/4.6.2/lto-wrapper Target: i686-mingw32 Configured with: ../src/gcc-4.6.2/configure --prefix=<PREFIX> --with-sysroot= --enable-languages=c,c++,fortran,objc,obj-c++,java --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=i686-pc-linux --target=i686-mingw32 Thread model: win32 gcc version 4.6.2 (GCC) --------------- Roumen |