Hi Roberto, I just started a Cygwin build of the snapshot. I'll let you know how it goes.
Regards, Keith
-----Original Message----- From: Roberto Bagnara [mailto:bagnara@cs.unipr.it] Sent: September 27, 2014 11:34 AM To: Keith Clifford Cc: 'The Parma Polyhedra Library developers' list' Subject: Re: FW: seg fault on override of a weak symbol in g++
On 08/15/14 20:28, Keith Clifford wrote:
One way of avoiding the whole issue and not having to worry about weak at all would be to move ppl_set_GMP_memory_allocation_functions() out of Init.cc into its own source file and include that file's object in the library. If the application defines ppl_set_GMP_memory_allocation_functions then the applications version will be used. If the application doesn't define it then the version from the library will be used.
The problem that I'm seeing only occurs if istream is included in the same file where a weak symbol is both defined and referenced. As long as the weak definition is in a different file from where its referenced the problem doesn't occur.
Hello Keith. Sorry for the long delay. We have followed your advice. You can test the Git head version or, if you prefer, use a just-uploaded PPL 1.2 snapshot available at
http://bugseng.com/products/ppl/download/ftp/snapshots/
Kind regards,
Roberto
-----Original Message----- From: Roberto Bagnara [mailto:bagnara@cs.unipr.it] Sent: August 14, 2014 7:54 AM To: Keith Clifford Cc: The Parma Polyhedra Library developers' list Subject: Re: FW: seg fault on override of a weak symbol in g++
On 08/05/14 01:07, Keith Clifford wrote:
This is just an update about the Seg Fault that I had building PPL last week. The issue is in the mingw compiler under certain circumstances which are described below if you're interested and in the attached files. The compiler and your test in the configure script indicate that the compiler supports weak symbols but it really doesn't under specific circumstances which the PPL build found. Anyway its in
Cygwin's hands now.
Hello Keith.
thanks for the update. Please keep me posted. I am thinking that, even if Cygwin people fixes the issue, this will not happen until some
time.
Perhaps we should change the configure script so as to perform a more precise detection. What do you think? Thanks again,
Roberto
-----Original Message----- From: Keith Clifford [mailto:kclifford@tranaptic.ca] Sent: August 4, 2014 2:10 PM To: 'cygwin@cygwin.com' Subject: seg fault on override of a weak symbol in g++
Hi, I was trying to build the ppl 1.1 library and got a seg fault when running one of the tests. I've narrowed it down to the attached test
case.
System: CYGWIN_NT-6.1 Keith-PC 1.7.31(0.272/5/3) 2014-07-25 11:26 x86_64 Cygwin
Both the following GCC's exhibit the problem Cygwin: Using built-in specs. COLLECT_GCC=i686-pc-mingw32-g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-mingw32/4.7.3/lto-wrapper.ex e Target: i686-pc-mingw32 Configured with: /usr/src/packages/mingw-gcc/64/mingw-gcc-4.7.3-1/src/gcc-4.7.3/config u re --srcdir=/usr/src/packages/mingw-gcc/64/mingw-gcc-4.7.3-1/src/gcc-4.7. 3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/mingw-gcc -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=i686-pc-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/i686-pc-mingw32/sys-root --with-build-sysroot=/usr/i686-pc-mingw32/sys-root --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --disable-multilib --enable-decimal-float=bid --disable-werror --enable-lto Thread model: win32 gcc version 4.7.3 (GCC)
Using built-in specs. COLLECT_GCC=i686-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.8.3/lto-wrapper.e x e Target: i686-w64-mingw32 Configured with: /cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc-4.8.3-1/ s rc/gcc -4.8.3/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc
4.8.3- 1/src/gcc-4.8.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-i686-gcc --htmldir=/usr/share/doc/mingw64-i686-gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=i686-w64-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/i686-w64-mingw32/sys-root --with-build-sysroot=/usr/i686-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,lto,objc,obj-c++ --enable-fully-dynamic-strings --enable-graphite --enable-libgomp --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-version-specific-runtime-libs --with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic --with-cloog-include=/usr/include/cloog-isl --with-system-zlib --libexecdir=/usr/lib Thread model: win32 gcc version 4.8.3 (GCC)
When built with the default Cygwin compiler the problem doesn't occur. Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/lto-wrapper.e x e Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.3-2/src/gcc-4.8.3/configur e --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.3-2/src/gcc-4.8.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib Thread model: posix gcc version 4.8.3 (GCC)
In the attached files in weak.cpp if the line static ios_base::Init __ioinit; is commented out the seg fault doesn't occur. Doing a disassembly of weak.o (objdump -d weak.o) shows that the call includes a nonzero offset that gets applied when the weak symbol is overridden by the function in strong.o. The offset is zero if the above mentioned line is
commented out.
Regards, Keith