From: Radu R. <rad...@mi...> - 2013-08-14 16:57:33
|
Hi, Is there any easy way to statically link against pthread? Using -lpthread always creates a dependency on pthreadGC2.dll, even when using -static. I also tried using libpthreadGC2.dll.a along with the other objects to be linked when producing the executable (instead of using -lpthread), but with no effect. I believe this is because libpthreadGC2.dll.a is just an "import library" and I'm statically linking the import wrappers, not the actual pthread functions. Thanks, Radu Rendec |
From: John B. <joh...@ho...> - 2013-08-14 17:20:30
|
On Wed, 14 Aug 2013 19:57:25 +0300, Radu Rendec wrote: > > Hi, > > Is there any easy way to statically link against pthread? Using > -lpthread always creates a dependency on pthreadGC2.dll, even when using > -static. > I believe that MinGW distributes only the DLL and its associated import library. If you want the static library, you will have to compile it yourself. > I also tried using libpthreadGC2.dll.a along with the other objects to > be linked when producing the executable (instead of using -lpthread), > but with no effect. I believe this is because libpthreadGC2.dll.a is > just an "import library" and I'm statically linking the import wrappers, > not the actual pthread functions. That is correct. The naming convention is that lib*.a is a static library and lib*.dll.a is an import library. Regards, John Brown. |
From: farmdve data.b. <fa...@da...> - 2013-08-14 19:41:20
|
Actually a static pthreads is actually very hard. You need to manually initialize pthreads and it gets a hell of a lot more complicated from then on. On Wed, Aug 14, 2013 at 8:20 PM, John Brown <joh...@ho...>wrote: > On Wed, 14 Aug 2013 19:57:25 +0300, Radu Rendec wrote: > > > > Hi, > > > > Is there any easy way to statically link against pthread? Using > > -lpthread always creates a dependency on pthreadGC2.dll, even when using > > -static. > > > > I believe that MinGW distributes only the DLL and its associated import > library. If you want the static library, you will have to compile it > yourself. > > > > I also tried using libpthreadGC2.dll.a along with the other objects to > > be linked when producing the executable (instead of using -lpthread), > > but with no effect. I believe this is because libpthreadGC2.dll.a is > > just an "import library" and I'm statically linking the import wrappers, > > not the actual pthread functions. > > That is correct. The naming convention is that lib*.a is a static > library and lib*.dll.a is an import library. > > Regards, > John Brown. > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Earnie B. <ea...@us...> - 2013-08-14 19:25:39
|
On Wed, Aug 14, 2013 at 12:57 PM, Radu Rendec wrote: > > Hi, > > Is there any easy way to statically link against pthread? Using > -lpthread always creates a dependency on pthreadGC2.dll, even when using > -static. > No, I'm not sure why but the package creation copies the libpthreadGC.dll.a to libpthread.a. Probably because there are issues with controlling the threads using a static library. I have yet to try testing the static library to see if it functions. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Radu R. <rad...@mi...> - 2013-08-15 07:24:39
|
On Wed, 2013-08-14 at 15:25 -0400, Earnie Boyd wrote: > No, I'm not sure why but the package creation copies the > libpthreadGC.dll.a to libpthread.a. Probably because there are issues > with controlling the threads using a static library. I have yet to > try testing the static library to see if it functions. I'm new to mingw, but my guess is that the file is copied for -lpthread to work as expected: -l<foo> causes the linker to search for lib<foo>.a or lib<foo>.so (lib<foo>.dll in case of mingw). According to older posts, the only issue with the static version is that you need to explicitly call an initialization function from your program, or else the program will crash on the first call to pthread_create(). I found this information here: http://mingw.5.n7.nabble.com/statically-linked-pthread-library-crashes-program-td17693.html However, that thread is almost 4 years old, and I haven't tested that myself on newer versions, so I'm not sure if it still applies. Radu |
From: Tony T. <ton...@gm...> - 2013-08-15 07:40:56
|
On 15/08/2013, at 5:24 PM, Radu Rendec <rad...@mi...> wrote: > On Wed, 2013-08-14 at 15:25 -0400, Earnie Boyd wrote: >> No, I'm not sure why but the package creation copies the >> libpthreadGC.dll.a to libpthread.a. Probably because there are issues >> with controlling the threads using a static library. I have yet to >> try testing the static library to see if it functions. > > I'm new to mingw, but my guess is that the file is copied for -lpthread > to work as expected: -l<foo> causes the linker to search for lib<foo>.a > or lib<foo>.so (lib<foo>.dll in case of mingw). > > According to older posts, the only issue with the static version is that > you need to explicitly call an initialization function from your > program, or else the program will crash on the first call to > pthread_create(). I found this information here: > > http://mingw.5.n7.nabble.com/statically-linked-pthread-library-crashes-program-td17693.html > > However, that thread is almost 4 years old, and I haven't tested that > myself on newer versions, so I'm not sure if it still applies. Version 2.9.1 introduced an autostatic[1] feature that removed the need to call pthread_win32_process_attach_np() and pthread_win32_process_detach_np() explicitly in most cases. The next release[2] should complete this so it's no longer required at all. Cheers, Tony [1] http://sourceware.org/ml/pthreads-win32/2010/msg00006.html [2] http://www.sourceware.org/pthreads-win32/news.html |
From: Earnie B. <ea...@us...> - 2013-08-15 12:03:30
|
On Thu, Aug 15, 2013 at 3:40 AM, Tony Theodore wrote: > > Version 2.9.1 introduced an autostatic[1] feature that removed the need to call pthread_win32_process_attach_np() > and pthread_win32_process_detach_np() explicitly in most cases. The next release[2] should complete this so it's no longer required at all. > > > [1] http://sourceware.org/ml/pthreads-win32/2010/msg00006.html > [2] http://www.sourceware.org/pthreads-win32/news.html > So when 2.10 becomes available we can distribute the static library. It is most definitely good news for those who prefer to use static. In the meantime it appears possible to use a static library but you must follow a few oddities to work around issues. However the delivered package from MinGW.org does not contain the static version so you must build it yourself. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Tony T. <ton...@gm...> - 2013-08-15 12:51:16
|
On 15/08/2013, at 10:03 PM, Earnie Boyd <ea...@us...> wrote: > On Thu, Aug 15, 2013 at 3:40 AM, Tony Theodore wrote: >> >> Version 2.9.1 introduced an autostatic[1] feature that removed the need to call pthread_win32_process_attach_np() >> and pthread_win32_process_detach_np() explicitly in most cases. The next release[2] should complete this so it's no longer required at all. >> >> >> [1] http://sourceware.org/ml/pthreads-win32/2010/msg00006.html >> [2] http://www.sourceware.org/pthreads-win32/news.html >> > > So when 2.10 becomes available we can distribute the static library. > It is most definitely good news for those who prefer to use static. > In the meantime it appears possible to use a static library but you > must follow a few oddities to work around issues. However the > delivered package from MinGW.org does not contain the static version > so you must build it yourself. In mxe, we patch it[1] to define "PTW32_STATIC_LIB" (since CFLAGS seem to be ignored) and build it with "make GC-static". This creates "libpthreadGC2.a" which is installed as "libpthread.a". Hope that helps anyone wishing to build a static version themselves. Tony [1] https://github.com/mxe/mxe/blob/master/src/pthreads-w32-1-fixes.patch |
From: Earnie B. <ea...@us...> - 2013-08-15 13:10:09
|
On Thu, Aug 15, 2013 at 8:51 AM, Tony Theodore wrote: > > In mxe, we patch it[1] to define "PTW32_STATIC_LIB" (since CFLAGS seem to be ignored) and build it with "make GC-static". This creates "libpthreadGC2.a" which is installed as "libpthread.a". > > Hope that helps anyone wishing to build a static version themselves. > > Tony > > [1] https://github.com/mxe/mxe/blob/master/src/pthreads-w32-1-fixes.patch Shouldn't the patch be to the GNUMakefile rather than these individual files? I'm considering releasing a real static lib with the 2.9.1 release I am close to uploading. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Tony T. <ton...@gm...> - 2013-08-15 13:51:33
|
On 15/08/2013, at 11:10 PM, Earnie Boyd <ea...@us...> wrote: > > Shouldn't the patch be to the GNUMakefile rather than these individual > files? I'm considering releasing a real static lib with the 2.9.1 > release I am close to uploading. Hmmmm, looking at GNUMakefile, I think the patch isn't required at all - the GC-static target should take care of it: ... CFLAGS = $(OPT) $(XOPT) -I. -DHAVE_PTW32_CONFIG_H -Wall ... GC-static: $(MAKE) XOPT="-DPTW32_BUILD_INLINED -DPTW32_STATIC_LIB" ... The recursive call should set CFLAGS correctly - I'll try removing the patch and see how it goes. Thanks for pointing that out. Tony |
From: Tony T. <ton...@gm...> - 2013-08-16 09:11:34
|
On 15/08/2013, at 11:51 PM, Tony Theodore <Ton...@gm...> wrote: > > On 15/08/2013, at 11:10 PM, Earnie Boyd <ea...@us...> wrote: >> >> Shouldn't the patch be to the GNUMakefile rather than these individual >> files? I'm considering releasing a real static lib with the 2.9.1 >> release I am close to uploading. > > Hmmmm, looking at GNUMakefile, I think the patch isn't required at all - the GC-static target should take care of it: > > ... > CFLAGS = $(OPT) $(XOPT) -I. -DHAVE_PTW32_CONFIG_H -Wall > ... > GC-static: > $(MAKE) XOPT="-DPTW32_BUILD_INLINED -DPTW32_STATIC_LIB" ... > > The recursive call should set CFLAGS correctly - I'll try removing the patch and see how it goes. > > Thanks for pointing that out. The patch is indeed redundant and has been removed from mxe, "make GC-static" is all that's required. Cheers, Tony |