Debian Bug report logs - #750741
built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Fri, 6 Jun 2014 15:02:45 +0200

Package: gcc-mingw-w64-i686
Version: 4.9.0-2+13
Severity: normal

Hello Stephen,
(this might be related to #748353)

I build a C library (libpari.dll) every day.
Since gcc-mingw-w64-i686 4.9.0-2+13, the DLL is depending on
libgcc_s_sjlj-1.dll and libwinpthread-1.dll (even though it do not use
pthread).

Having to ship libwinpthread-1.dll and libgcc_s_sjlj-1.dll
is a usability problem given the target audience.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #10 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Bill Allombert <ballombe@debian.org>, 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Fri, 6 Jun 2014 22:49:46 +0200

[Message part 1 (text/plain, inline)]

Hi Bill,

On Fri, 6 Jun 2014 15:02:45 +0200, Bill Allombert <ballombe@debian.org> wrote:
> Hello Stephen,
> (this might be related to #748353)

I believe it is...

> I build a C library (libpari.dll) every day.
> Since gcc-mingw-w64-i686 4.9.0-2+13, the DLL is depending on
> libgcc_s_sjlj-1.dll and libwinpthread-1.dll (even though it do not use
> pthread).
> 
> Having to ship libwinpthread-1.dll and libgcc_s_sjlj-1.dll
> is a usability problem given the target audience.

I'm working on figuring out some way to provide a package which allows
building for pthreads or Win32 threads, which would fix your problem (but
still allow people using std::thread and such things to use mingw-w64 too).

In the mean time, if you like you can rebuild gcc-mingw-w64 with native Win32
threads, which will avoid the above dependencies (at least
libwinpthread-1.dll). You just need to fetch the gcc-mingw-w64 source and
modify line 137 of debian/rules so that it reads

	--enable-threads=win32 \

instead of

	--enable-threads=posix \

The resulting set of packages will avoid the pthreads dependency unless you
use OpenMP with libgomp.

If you do try this, could you let me know if it also drops the
libgcc_s_sjlj-1.dll dependency?

Alternatively, if you can explain how you build PARI/GP (if I've guessed
correctly) as libpari.dll, I can look into it in more detail...

Regards,

Stephen

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Stephen Kitt <skitt@debian.org>

Cc: Bill Allombert <ballombe@debian.org>, 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Sat, 7 Jun 2014 00:01:15 +0200

On Fri, Jun 06, 2014 at 10:49:46PM +0200, Stephen Kitt wrote:
> Hi Bill,
> 
> On Fri, 6 Jun 2014 15:02:45 +0200, Bill Allombert <ballombe@debian.org> wrote:
> > Hello Stephen,
> > (this might be related to #748353)
> 
> I believe it is...

OK, at least I figured out why my program was crashing at start up
and how to fix it.

> > I build a C library (libpari.dll) every day.
> > Since gcc-mingw-w64-i686 4.9.0-2+13, the DLL is depending on
> > libgcc_s_sjlj-1.dll and libwinpthread-1.dll (even though it do not use
> > pthread).
> > 
> > Having to ship libwinpthread-1.dll and libgcc_s_sjlj-1.dll
> > is a usability problem given the target audience.
> 
> I'm working on figuring out some way to provide a package which allows
> building for pthreads or Win32 threads, which would fix your problem (but
> still allow people using std::thread and such things to use mingw-w64 too).
> 
> In the mean time, if you like you can rebuild gcc-mingw-w64 with native Win32
> threads, which will avoid the above dependencies (at least
> libwinpthread-1.dll). You just need to fetch the gcc-mingw-w64 source and
> modify line 137 of debian/rules so that it reads
> 
> 	--enable-threads=win32 \
> 
> instead of
> 
> 	--enable-threads=posix \
> 
> The resulting set of packages will avoid the pthreads dependency unless you
> use OpenMP with libgomp.
> 
> If you do try this, could you let me know if it also drops the
> libgcc_s_sjlj-1.dll dependency?

OK I will try that.

> Alternatively, if you can explain how you build PARI/GP (if I've guessed
> correctly) as libpari.dll, I can look into it in more detail...

Indeed. But it is not that urgent now that I understand the issue.

I wrote a summary some year ago:
<http://pari.math.u-bordeaux.fr/archives/pari-dev-0912/msg00013.html>
the build log is 
<http://pari.math.u-bordeaux.fr/buildlogs/986eab0c-7336-48ba-ade0-9fd9749cae94>

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #20 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Stephen Kitt <skitt@debian.org>

Cc: Bill Allombert <ballombe@debian.org>, 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Tue, 17 Jun 2014 16:32:07 +0200

On Fri, Jun 06, 2014 at 10:49:46PM +0200, Stephen Kitt wrote:
> Hi Bill,
> 
> On Fri, 6 Jun 2014 15:02:45 +0200, Bill Allombert <ballombe@debian.org> wrote:
> > Hello Stephen,
> > (this might be related to #748353)
> 
> I believe it is...
> 
> > I build a C library (libpari.dll) every day.
> > Since gcc-mingw-w64-i686 4.9.0-2+13, the DLL is depending on
> > libgcc_s_sjlj-1.dll and libwinpthread-1.dll (even though it do not use
> > pthread).
> > 
> > Having to ship libwinpthread-1.dll and libgcc_s_sjlj-1.dll
> > is a usability problem given the target audience.
> 
> I'm working on figuring out some way to provide a package which allows
> building for pthreads or Win32 threads, which would fix your problem (but
> still allow people using std::thread and such things to use mingw-w64 too).
> 
> In the mean time, if you like you can rebuild gcc-mingw-w64 with native Win32
> threads, which will avoid the above dependencies (at least
> libwinpthread-1.dll). You just need to fetch the gcc-mingw-w64 source and
> modify line 137 of debian/rules so that it reads
> 
> 	--enable-threads=win32 \
> 
> instead of
> 
> 	--enable-threads=posix \
> 
> The resulting set of packages will avoid the pthreads dependency unless you
> use OpenMP with libgomp.
> 
> If you do try this, could you let me know if it also drops the
> libgcc_s_sjlj-1.dll dependency?

I did it but it does not change the dependencies:

$ i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.9/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking
--prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-threads=win32 --enable-fully-dynamic-string
--enable-sjlj-exceptions --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++ --enable-lto --with-plugin-ld --target=i686-w64-mingw32 --with-gxx-include-dir=/usr/include/c++/4.9 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld
Thread model: win32
gcc version 4.9.0 (GCC)

However the resulting libpari.dll still require both libwinpthread-1.dll and
libgcc_s_sjlj-1.dll.

err:module:import_dll Library libgcc_s_sjlj-1.dll (which is needed by L"Z:\\home\\bill\\pari\\Omingw-i686\\libpari.dll") not found
err:module:import_dll Library libpari.dll (which is needed by L"Z:\\home\\bill\\pari\\Omingw-i686\\gp-dyn") not found
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\bill\\pari\\Omingw-i686\\gp-dyn" failed, status c0000135

I double checked everything.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #27 received at 750741-close@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: 750741-close@bugs.debian.org

Subject: Bug#750741: fixed in gcc-mingw-w64 14

Date: Mon, 28 Jul 2014 06:49:33 +0000

Source: gcc-mingw-w64
Source-Version: 14

We believe that the bug you reported is fixed in the latest version of
gcc-mingw-w64, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 750741@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stephen Kitt <skitt@debian.org> (supplier of updated gcc-mingw-w64 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 28 Jul 2014 01:41:35 +0200
Source: gcc-mingw-w64
Binary: gcc-mingw-w64 gcc-mingw-w64-i686 gcc-mingw-w64-x86-64 g++-mingw-w64 g++-mingw-w64-i686 g++-mingw-w64-x86-64 gfortran-mingw-w64 gfortran-mingw-w64-i686 gfortran-mingw-w64-x86-64 gobjc-mingw-w64 gobjc-mingw-w64-i686 gobjc-mingw-w64-x86-64 gobjc++-mingw-w64 gobjc++-mingw-w64-i686 gobjc++-mingw-w64-x86-64 gcc-mingw-w64-base mingw32
Architecture: source all amd64
Version: 14
Distribution: unstable
Urgency: medium
Maintainer: Stephen Kitt <skitt@debian.org>
Changed-By: Stephen Kitt <skitt@debian.org>
Description:
 g++-mingw-w64 - GNU C++ compiler for MinGW-w64
 g++-mingw-w64-i686 - GNU C++ compiler for MinGW-w64 targeting Win32
 g++-mingw-w64-x86-64 - GNU C++ compiler for MinGW-w64 targeting Win64
 gcc-mingw-w64 - GNU C compiler for MinGW-w64
 gcc-mingw-w64-base - GNU Compiler Collection for MinGW-w64 (base package)
 gcc-mingw-w64-i686 - GNU C compiler for MinGW-w64 targeting Win32
 gcc-mingw-w64-x86-64 - GNU C compiler for MinGW-w64 targeting Win64
 gfortran-mingw-w64 - GNU Fortran compiler for MinGW-w64
 gfortran-mingw-w64-i686 - GNU Fortran compiler for MinGW-w64 targeting Win32
 gfortran-mingw-w64-x86-64 - GNU Fortran compiler for MinGW-w64 targeting Win64
 gobjc++-mingw-w64 - GNU Objective-C++ compiler for MinGW-w64
 gobjc++-mingw-w64-i686 - GNU Objective-C++ compiler for MinGW-w64 targeting Win32
 gobjc++-mingw-w64-x86-64 - GNU Objective-C++ compiler for MinGW-w64 targeting Win64
 gobjc-mingw-w64 - GNU Objective-C compiler for MinGW-w64
 gobjc-mingw-w64-i686 - GNU Objective-C compiler for MinGW-w64 targeting Win32
 gobjc-mingw-w64-x86-64 - GNU Objective-C compiler for MinGW-w64 targeting Win64
 mingw32    - Minimalist GNU win32 (cross) compiler (transition package)
Closes: 179760 281030 317146 338412 351790 403720 418167 470574 470873 484299 498400 514186 514187 525016 583262 748353 750741 756142
Changes:
 gcc-mingw-w64 (14) unstable; urgency=medium
 .
   * Provide compilers using Windows and POSIX threads. The default setup
     uses Windows threads, thus avoiding the dependency on the pthreads DLL
     (Closes: #748353, #750741).
   * Use the default exception-handling (SJLJ on 32-bit Windows, SEH on
     64-bit Windows). (With the above, LP: #1338043.)
   * Build a mingw32 transition package (Closes: #756142):
     - C++ code with interface/implementation pragmas links correctly
       (Closes: #179760);
     - libstdc++.la is no longer shipped (Closes: #281030);
     - the libstdc++ DLL is provided (Closes: #317146);
     - _NO_OLD_NAMES doesn't break unistd.h (Closes: #338412);
     - the gccbug manpage is no longer linked to (Closes: #351790);
     - the package description doesn't mention "freedom through
       obsolescence" (Closes: #403720);
     - g77 is provided (Closes: #418167);
     - nothing is installed in /usr/libexec (Closes: #470574);
     - Lintian overrides are correct (Closes: #470873);
     - powf and sinf can be used in the same project (Closes: #484299);
     - there's no "it's"/"its" typo in the Debian-specific files (Closes:
       #498400);
     - the package builds gcc 4.9 (Closes: #514186);
     - a 64-bit compiler is available (Closes: #514187);
     - powf is defined correctly (Closes: #525016);
     - no compilercache symlinks are shipped (Closes: #583262).
   * Ship the C++ header files in the default location instead of
     /usr/include/c++/; this avoids having to introduce a new package for
     the target-independent headers.
   * Remove obsolete gnat files.
Checksums-Sha1:
 9007ff8b0217477e86ccdeccabf545a2c10cb2e7 2946 gcc-mingw-w64_14.dsc
 9b0eedefed891f56d15d78a5991597ab3cecd5a7 23604 gcc-mingw-w64_14.tar.xz
 81af6d09c3e1cabf298beee9b414b509391ba067 1198 gcc-mingw-w64_4.9.1-2+14_all.deb
 b3321ccd3a11247d19846e0ab87b5e396f281645 1016 g++-mingw-w64_4.9.1-2+14_all.deb
 0b5bed2c01e92ad45503d698b136812e2b098fab 1024 gfortran-mingw-w64_4.9.1-2+14_all.deb
 bc8b76797925f9625c4d6a51124bba96e733bf92 1028 gobjc-mingw-w64_4.9.1-2+14_all.deb
 e7adf790163a46dc8a339612740936ac80c74d8c 1032 gobjc++-mingw-w64_4.9.1-2+14_all.deb
 c17dde740f8ba29a8cb8b27b395614347035671e 1352 mingw32_4.9.1-2+14_all.deb
 030fd5e87d7550d2673c2163f778c47c799c7b81 23376810 gcc-mingw-w64-i686_4.9.1-2+14_amd64.deb
 71d1c22f5da9776088b7d11dd1663cd9824d2039 23448416 gcc-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 21102d5fff60c05f238ed7ed0e55aed957542157 16054664 g++-mingw-w64-i686_4.9.1-2+14_amd64.deb
 fd89fc8162cb1a631deb5f8c0ef0d59a1fbba05c 16524660 g++-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 7254ac0c30ceadce5f9377183e69c10bb62b8209 12530770 gfortran-mingw-w64-i686_4.9.1-2+14_amd64.deb
 e3bc0d480fc12fa30509f6be496c7533a0fb2379 13296656 gfortran-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 abb99c9646faa21f25ea0ee41adecd50c961b052 10142982 gobjc-mingw-w64-i686_4.9.1-2+14_amd64.deb
 0382794a5799091be2f9d35e5ce6caba0ed80e1a 10331134 gobjc-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 68d4fd5856c69549b24cabc8e213612399320464 10605282 gobjc++-mingw-w64-i686_4.9.1-2+14_amd64.deb
 987cf60bfed7c77ccb22d7dc70540798ba35b2f2 10755940 gobjc++-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 0224181a7823fb5b8f41127a77535b096c7aff0d 159500 gcc-mingw-w64-base_4.9.1-2+14_amd64.deb
Checksums-Sha256:
 c94eeb93876e590e0f9fb99c9696b6ba51fcd2bb94b6510e7b27fce1d814df42 2946 gcc-mingw-w64_14.dsc
 e0223fec48f67139ca8e91d8e4a7ca456a37d552536a5cd7e59bacd82a9a15e1 23604 gcc-mingw-w64_14.tar.xz
 503926038c54b322b11c330b1f8a750d8ec931db6fb9e8268269428ddf5711ac 1198 gcc-mingw-w64_4.9.1-2+14_all.deb
 6e6e1dfe4bb4f926e4628373021dbb5cb9568e6ffa58e24b32e98e36c07bc55d 1016 g++-mingw-w64_4.9.1-2+14_all.deb
 694b020f0048c7f1f67201e1e9aaf59eae38f53450efb356d1a3ec24874e5bdc 1024 gfortran-mingw-w64_4.9.1-2+14_all.deb
 82a6d670ae3cc9edf70937404ed878466465d11a67ecb3d520ec62f60bd2ef67 1028 gobjc-mingw-w64_4.9.1-2+14_all.deb
 b37e873f1e02ea1fc2c0a8b7d2721beb89f3e87435a5c894ddaf78553e073d09 1032 gobjc++-mingw-w64_4.9.1-2+14_all.deb
 d30ff231ff5167b6f9a4bf28642967c2bf029ea86ff24abc4dc5e32810a6f645 1352 mingw32_4.9.1-2+14_all.deb
 aeea7f3838cf023edd5bc0ed55c10afd7783ad4853083b669a3c1dba483658d3 23376810 gcc-mingw-w64-i686_4.9.1-2+14_amd64.deb
 4384f32d71be5e29ca8151af6c54fcbc5f5e07c831e0ccc2f2297aa998cc3674 23448416 gcc-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 7158ff305bbb2c328c3bf3cf964e5eae6002e6bbcacca4dd98b595646991d578 16054664 g++-mingw-w64-i686_4.9.1-2+14_amd64.deb
 a646602e919d97fc70d29975b367c29eedc4a2d65f8233a50c9cec5b8119aa3c 16524660 g++-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 13f2f359cc69b4f0ecb323173e26ddc9f9288da12f84a47cd8e7a25baac431b6 12530770 gfortran-mingw-w64-i686_4.9.1-2+14_amd64.deb
 c9dfc66d25a76e1e2f4a9d78f81805879b1032c0f4f88afeb90b9332b26616f6 13296656 gfortran-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 7e05fcc0b0bd08f728ffff574d62f23a75ab49618614ea62d36815d4810cacbc 10142982 gobjc-mingw-w64-i686_4.9.1-2+14_amd64.deb
 2c0acbe71fa789bb6e9a903b4f3cd352c132c9c3a96fff26124eb8005e50ba62 10331134 gobjc-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 da031af94ce88ec0fdac1be0808780ba706d6f0a6c4f2108ebc8d201cab5b101 10605282 gobjc++-mingw-w64-i686_4.9.1-2+14_amd64.deb
 d4f39875498f14d7934bbf6d5a586793a318dd1ddbec6db620563deb4fb4b248 10755940 gobjc++-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 86fe1963d5bae97bc9d0a16d37281fb5b9f045da6c15302dc1b9963fa8dc9f07 159500 gcc-mingw-w64-base_4.9.1-2+14_amd64.deb
Files:
 bd56f7f17aa245dd128180a46c0fae13 1198 devel extra gcc-mingw-w64_4.9.1-2+14_all.deb
 abbcd8b2c2ab6e11dce73fc1c6b0cd38 1016 devel extra g++-mingw-w64_4.9.1-2+14_all.deb
 0042dcc34821dd82daa64e07b1edab0e 1024 devel extra gfortran-mingw-w64_4.9.1-2+14_all.deb
 f287e899d31bdf956972d064b651313f 1028 devel extra gobjc-mingw-w64_4.9.1-2+14_all.deb
 727d5a14e5e95ff8ab7d31a067657501 1032 devel extra gobjc++-mingw-w64_4.9.1-2+14_all.deb
 63417a6ddbd08a4e5f09f4e4f4e6e776 1352 devel extra mingw32_4.9.1-2+14_all.deb
 f53f75ef1d94d621b7b3e9e9a6c6ef0b 23376810 devel extra gcc-mingw-w64-i686_4.9.1-2+14_amd64.deb
 12a292fee30ac2b2f41743517ca0b00b 23448416 devel extra gcc-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 a1d66282d391949789fb6c41b5075010 16054664 devel extra g++-mingw-w64-i686_4.9.1-2+14_amd64.deb
 a35ac80e5245df2deef33b995ef8fa8a 16524660 devel extra g++-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 420590588e5b702287c6341b2b93d4c8 12530770 devel extra gfortran-mingw-w64-i686_4.9.1-2+14_amd64.deb
 e6c145bf41810048d75fe8cf767c5a5b 13296656 devel extra gfortran-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 4171ebd697c036625dfb067c8563b94f 10142982 devel extra gobjc-mingw-w64-i686_4.9.1-2+14_amd64.deb
 1685568edab8c26358c93f26a2f46f58 10331134 devel extra gobjc-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 e43de3ddb73b55bd0d0b1c4611d24e49 10605282 devel extra gobjc++-mingw-w64-i686_4.9.1-2+14_amd64.deb
 591a167c5372ada0fa9da76f42f37127 10755940 devel extra gobjc++-mingw-w64-x86-64_4.9.1-2+14_amd64.deb
 6c4d799dc4d22f5651290489feb97284 159500 devel extra gcc-mingw-w64-base_4.9.1-2+14_amd64.deb
 02d0da04b0765f7088843d5fc0c11561 2946 devel extra gcc-mingw-w64_14.dsc
 376032c669bf7857382dac5ad02b8da0 23604 devel extra gcc-mingw-w64_14.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJT1d6BAAoJEHWXeKmja0lPlEQP/3dujpSqLu78r7LmwiSd/NmP
S9E3xotj2LYBw5Z4AxFc/XFeAQlZ/6ojPds52VTfGWqheL+oOgZ72UVa53noROaQ
pO4sAoIduIA+oJMldKn1i5GMdAd3nvAmobqG0edz7Jf0Qod12S3bbLMGb+pHJBHt
Eetr/lw4nW/9qcNsGoAQ6Oq4ap9hk8Ya8qgISYD51VJO1/Fv/w7TlQDMO0OGG28o
vxocH5Fp35zPM0gNkz5aaADZJFttdE88AdAnmseRLjXIxoI4iWmomNPruMd1hGfK
vts89yWPsrB/UYpg1lt6vjAnFA9NMq8NHNaPTCJ5+IPkwt03j1Tsam3FEU3Xfc7z
q/WJj2XnF4QcQQORV90Bxe+jnYucoibUoiOnU35oh821Ph7lv5wklXOf+6ugnjBj
GzVRzpV7Nr4euyoHCTOteJdzHoSHpo0FjZEADzQ5b3EEErSuzmO+UBUyEcJ/fZoB
OVlGG3U6Jnb2HWm375TQh7J0KoGjMW547Fe+chfY9Xe0gaPhJ9Su7ql7y/nTLffk
eljhZHFz+3mNcivkdyvWRL2R+7Ek9l8GUVL2wafmUAbF8XtaMry6OwKirAM0Yv/Q
mpfZEuLYrcOi6Cot7ew0w9L3SJ/dZDAj5j4/65mQTap6bfgY+xpYN2agjFvEFr0z
VhoKkubO9ZimSfnPObSM
=wHYV
-----END PGP SIGNATURE-----

Message #32 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Bill Allombert <ballombe@debian.org>

Cc: Stephen Kitt <skitt@debian.org>, 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Mon, 11 Aug 2014 22:25:18 +0200

On Tue, Jun 17, 2014 at 04:32:07PM +0200, Bill Allombert wrote:
> > If you do try this, could you let me know if it also drops the
> > libgcc_s_sjlj-1.dll dependency?
> 
> I did it but it does not change the dependencies:

Hello Stephen,
I checked with your new package, and I still get a libgcc_s_sjlj-1.dll
dependency. However, it seems to be linked with the use of gettimeofday().
If I use ftime() instead of gettimeofday, the dependency disappears.

Do you know something about it ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #37 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Bill Allombert <ballombe@debian.org>

Cc: 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Tue, 12 Aug 2014 23:12:25 +0200

[Message part 1 (text/plain, inline)]

Hi Bill,

On Mon, 11 Aug 2014 22:25:18 +0200, Bill Allombert <ballombe@debian.org>
wrote:
> On Tue, Jun 17, 2014 at 04:32:07PM +0200, Bill Allombert wrote:
> > > If you do try this, could you let me know if it also drops the
> > > libgcc_s_sjlj-1.dll dependency?
> > 
> > I did it but it does not change the dependencies:
> 
> I checked with your new package, and I still get a libgcc_s_sjlj-1.dll
> dependency. However, it seems to be linked with the use of gettimeofday().
> If I use ftime() instead of gettimeofday, the dependency disappears.
> 
> Do you know something about it ?

Is this when building PARI? I suppose not, at least I didn't see
gettimeofday() being used there... (I'm asking because my libpari.dll doesn't
need libgcc.)

Anyway, regarding gettimeofday(), I don't see anything which would end up
requiring libgcc. Building the following program

#include <sys/time.h>
#include <stdio.h>

int main(int argc, char **argv) {
  struct timeval tv;
  struct timezone tz;
  if (!gettimeofday(&tv, &tz)) {
    printf("%d\n", tv.tv_sec);
  }
}


for both 32-bit and 64-bit targets produces a working executable which
doesn't require libgcc.

How are you using the results from gettimeofday() and ftime()?

If you build your code for a Linux-based target, do you end up with a
dependency on libgcc_s.so.1?

Regards,

Stephen

[signature.asc (application/pgp-signature, attachment)]

Message #42 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Stephen Kitt <skitt@debian.org>

Cc: Bill Allombert <ballombe@debian.org>, 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Thu, 14 Aug 2014 22:14:41 +0200

[Message part 1 (text/plain, inline)]

On Tue, Aug 12, 2014 at 11:12:25PM +0200, Stephen Kitt wrote:
> Hi Bill,
> 
> On Mon, 11 Aug 2014 22:25:18 +0200, Bill Allombert <ballombe@debian.org>
> wrote:
> > On Tue, Jun 17, 2014 at 04:32:07PM +0200, Bill Allombert wrote:
> > > > If you do try this, could you let me know if it also drops the
> > > > libgcc_s_sjlj-1.dll dependency?
> > > 
> > > I did it but it does not change the dependencies:
> > 
> > I checked with your new package, and I still get a libgcc_s_sjlj-1.dll
> > dependency. However, it seems to be linked with the use of gettimeofday().
> > If I use ftime() instead of gettimeofday, the dependency disappears.
> > 
> > Do you know something about it ?
> 
> Is this when building PARI? I suppose not, at least I didn't see
> gettimeofday() being used there... (I'm asking because my libpari.dll doesn't
> need libgcc.)

This is in the GIT repository. I found this issue by doing a bisection.

> Anyway, regarding gettimeofday(), I don't see anything which would end up
> requiring libgcc. Building the following program
> 
> #include <sys/time.h>
> #include <stdio.h>
> 
> int main(int argc, char **argv) {
>   struct timeval tv;
>   struct timezone tz;
>   if (!gettimeofday(&tv, &tz)) {
>     printf("%d\n", tv.tv_sec);
>   }
> }
> 
> 
> for both 32-bit and 64-bit targets produces a working executable which
> doesn't require libgcc.

Indeed, but you are not building a DLL there. Only the dynamic libpari.dll is
affected. I join an archive that should allow you to reproduce this.
But this is not an urgent issue.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

[gtod.tgz (application/x-gtar-compressed, attachment)]

Message #47 received at 750741@bugs.debian.org (full text, mbox, reply):

From: Stephen Kitt <skitt@debian.org>

To: Bill Allombert <ballombe@debian.org>, 750741@bugs.debian.org

Subject: Re: Bug#750741: built DLL depending on libgcc_s_sjlj-1.dll and libwinpthread-1.dll

Date: Sat, 23 Aug 2014 15:59:38 -0700

[Message part 1 (text/plain, inline)]

Hi Bill,

On Thu, 14 Aug 2014 22:14:41 +0200, Bill Allombert <ballombe@debian.org>
wrote:
> Indeed, but you are not building a DLL there. Only the dynamic libpari.dll
> is affected. I join an archive that should allow you to reproduce this.
> But this is not an urgent issue.

I have figured out why this is happening; in fact there's a bug filed against
MinGW (not MinGW-w64) about it, with a detailed explanation:
http://sourceforge.net/p/mingw/bugs/2065/

Regards,

Stephen

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.