This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch,build] Build libgfortran and libgomp as DLL on win32
- From: "François-Xavier Coudert" <fxcoudert at gmail dot com>
- To: fortran at gcc dot gnu dot org
- Cc: "Danny Smith" <dannysmith at clear dot net dot nz>, gcc-patches <gcc-patches at gcc dot gnu dot org>, cgf at gcc dot gnu dot org
- Date: Wed, 29 Aug 2007 13:40:48 +0100
- Subject: Re: [patch,build] Build libgfortran and libgomp as DLL on win32
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LHopAaXjMguuPrzeUd89/ZzTInQb6BMoBdpzA+D00Lwlgk6RB2IMVBoVrQrQ1HmpnGtqJHCsXEZFN+9YQlw1g3rtvXKasMrzIUgQnn2NxvGxAXwNn9wdVvqgHsLIdi+fvLczu2zv5GP/Wk12GiUgerd8jsF7M4rIjQ93+Dt+l9A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WSIZWAtIjyhos5m7MiOEn8jLBDDL6VVkeqnq0GMwctlbNz0LfyVqeTyTYEcH9vdM8fnj7bKEO8ueZ3A2itHXRBo8WYcQesbtmfCVb+fNQy6w4k+rsjEwKhLmRFl8DpxGgiti+B+ycJQL90FMeAc/JJycDbegqkkx1ACCgEUwEWQ=
- References: <19c433eb0708280647y24b9198ge3195c9fe85487f2@mail.gmail.com> <000301c7e9b5$fe5d0590$ef4861cb@THOMAS> <19c433eb0708290345p55f0178bte5c5c6123d06525b@mail.gmail.com> <46D5676D.B7BFEEF3@dessent.net>
>> For symbol versioning, configure checks that -shared
>> -Wl,--version-script is supported, and finds that it is. So, it's
>> passed as linker flags (e.g.,
>> -Wl,--version-script=$(srcdir)/gfortran.map). I don't know how to
>> check the resulting DLL to see if symbol versioning is indeed present,
>> but if you tell me how to do it, I will.
>
> This seems wrong. There is no such thing as symbol versioning on PE so
> this test should fail.
Well, maybe --version-script is a no-op, but it's accepted by the linker.
> IMO the best user experience would be achieved by assuming the user has
> pthreads-win32 and adding -lpthreadGC2 via the specs file when -fopenmp
> is specified. If the user doesn't have the pthread library installed
> they get a link error, but that's better than the alternative where the
> user has to specify "-fopenmp -lpthreadGC2".
There is no need to use -lpthreadGC2: -fopenmp gives -lpthread to the
linker, and libpthread.a implies that pthreadGC2.dll comes into play.
You never have to specify -lpthreadGC2.
>> 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. Build maintainers, OK to commit?
>
> I think this issue is a lot more involved than simply adding
> -no-undefined. What about __declspec(dllimport) in the libstdc++
> headers? Otherwise you rely on auto-import which has its own problems.
OK, I then withdraw the updated patch. I'll let C++ or mingw
maintainers deal with it.
Thanks,
FX