This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [patch,build] Build libgfortran and libgomp as DLL on win32


> 
> > For thread support you need to build dll with -mthreads
> 
> Hum, that one has me puzzled. The doc for this option says it's
> required for thread-safe exception handling: wouldn't you need it also
> for static libraries? In any case, I've looked and it's not currently
> used (well, it is implied by -fopenmp when compiling user code, but
> it's not used for compilation of our runtime libraries). Maybe this
> could be put into a toplevel config/mt-mingw file?

Dll most have all symbols defined  If you build dll without -mthreads
the dll will resolve the variable _CRT_MT to the one in the static
libmingw.a. The value of this  variable is 0, which means single thread.
This is turn makes _gthread_active_p return false within the dll, so yes
everything will work if you don't need thread support, but a
multithread app that uses the libgfortan random may randomly crash.


> 
> > I believe that shared runtime dll's also need to be built with
> > shared-libgcc.
> 
> Why? I did all my testing with a static libgcc, and it works fine.
> Even on other systems, you can use -static-libgcc with shared runtime
> libraries.

Shared libgcc is required if you want to follow Dwarf2 unwind info
across dll/exe boundaries. 

> 
> > How is dependency on pthread.dll handled for mingw? Do you 
> force use of
> > a specific version of the third-party prthreads-win32 dll?
> 
> I think this is orthogonal to the shared runtime libraries support. By
> default, libgomp isn't built on mingw, but if you have a libpthread
> accessible, you can configure with --enable-libgomp. I do it with
> pthreads-win32, but it could be any pthreads library, really. In the
> case of pthreads-win32, they have a libpthread.a and a pthreadGC2.dll.
> Linking in libpthread.a creates a dependency on pthreadGC2.dll. From
> what I understand, a libgomp built with a given version of
> pthreads-win32 would work with any later version in the 2.x series,
> but it's probably safer to use the same version.

If you build libgomp as dll, the dll will depend on the specific pthread
dll that you name at dll-build time. The user must have a dll with at
least the same name in PATH

-lpthread will only imply pthreadGC2.dll if you rename libpthreadGC2.a
to libpthread.a

> 
> 
> OK, well, I've expanded my patch to also allow building DLLs for
> libssp and libstdc++-v3. Please find attached the new patch and
> ChangeLog.


You really do need to run these things through a testsuite. 
libstdc++.dll will not work for anything that reguires typeinfo as you
build it. 

Danny

 Build maintainers, OK to commit?
> 
> FX
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]