On 3/22/2010 07:24, Doug Semler wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler<[email protected]> wrote:
Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
target DLLs for things like libstdc++, etc are installed into the
completely wrong spot due to a -bindir parameter in the libtool portion
of the DLL makefiles. They are installed into the host's binary
directory (which makes no sense to me at all - by the way I use a
different -prefix and -exec-prefix), they cannot be overridden by the
--with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden
and which I have working multilib with a minor patch to
gcc/config/t-cygming), nor do they obey the version specific runtime
libs directory like the native toolchain does. In addition, the
mulitlib install can clobber the dlls in that (wrong) bindir with the
wrong arch type (the 32bit install puts the 64 bit version there after
all is said and done).
Jon Y has a patch for all of that.
Given that the trunk of GCC is in stage 4, I wouldn't expect any of this
to be fixed prior to the release even if patches were submitted since I
wouldn't expect this to be classified as a P1 issue (I don't think the
w64-mingw32 toolchain is considered to be a primary target, is it?)
Yeah, it's not getting fixed in 4.5. And no, we aren't even a
secondary target :(
My frustration right now is that the GCC trunk has been in stage 4 since
December...aside from the fact that I would be wary personally of moving
to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for
these targets...
After saying all that, the documentation about multilib should maybe have
some caveats...
Well, to be fair, we never advertised that it even exists... so.....
In both how-to-build docs, yes, you do :)
I know that there was the "the tools now track gcc" statement and "no more
need to patch gcc." One of the problems really is going to be requiring the
use of the 4.6 trunk to get the correct behavior for installation of the
toolchain (multilib notwithstanding, I still feel the installation of the
target DLLs is also woefully incorrect, so I presume the patch mentioned above
does that as well) unless there are also plans to backport them to 4.5, which
I would doubt. I would never use the stage 1,2, or 3 trunks to build
production code (well, maybe the stage 3 depending on the issues in it)-- they
are just too unstable --which means I'll track the 4.5 branch for quite a
while.
Don't know what I'll do...wait for the patch(es) to be applied, do the work
myself, or just deal with it (using nonmultilib, moving the files to where they
should be, and modifying the installed .la files correctly...)
OK...vent mode off :)
Hi,
here are the patches to make the dlls not clash, "v1.patch" for
libtool, "gcc_multilib.patch" for gcc. The dlls are prefixed "w32" and
"w64" respectively.
You'll need to regenerate the gcc configury, particularly for the
target support libs, after installing a patched version of libtool.
I'm still waiting for the FSF paperwork to be done.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 80a1ff3..45798fc 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4215,6 +4215,28 @@ func_mode_link ()
continue
;;
+ -m32)
+ archive_cmds="$archive_cmds -m32"
+ case $host in
+ *-w64-mingw*)
+ MULTILIB_PREFIX=l32
+ ;;
+ *) ;;
+ esac
+ continue
+ ;;
+
+ -m64)
+ archive_cmds="$archive_cmds -m64"
+ case $host in
+ *-w64-mingw*)
+ MULTILIB_PREFIX=l64
+ ;;
+ *) ;;
+ esac
+ continue
+ ;;
+
-no-undefined)
allow_undefined=no
continue
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 29f1222..f6bb69a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2084,6 +2084,7 @@ BEGIN {RS=" "; FS="/|\n";} {
else
sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
fi])
+MULTILIB_PREFIX=
library_names_spec=
libname_spec='lib$name'
soname_spec=
@@ -2227,6 +2228,22 @@ m4_if([$1], [],[
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ case $host_vendor in
+ w64)
+ soname_spec='`echo ${libname} | sed -e
's/^lib/\${MULTILIB_PREFIX}/'``echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ case $host in
+ x86_64-*)
+ MULTILIB_PREFIX=l64
+ ;;
+ i?86-*)
+ MULTILIB_PREFIX=l32
+ ;;
+ esac
+ ;;
+ *)
+ soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+ ;;
+ esac
;;
pw32*)
# pw32 DLLs use 'pw' prefix rather than 'lib'
@@ -2705,6 +2722,8 @@ _LT_DECL([], [libname_spec], [1], [Format of library name
prefix])
_LT_DECL([], [library_names_spec], [1],
[[List of archive names. First name is the real one, the rest are links.
The last name is the one that the linker finds with -lNAME]])
+_LT_DECL([], [MULTILIB_PREFIX], [0],
+ [MULTILIB PREFIX STRING])
_LT_DECL([], [soname_spec], [1],
[[The coded name of the library, if different from the real name]])
_LT_DECL([], [install_override_mode], [1],
Index: gcc/config/i386/t-mingw-w64
===================================================================
--- gcc/config/i386/t-mingw-w64 (revision 156923)
+++ gcc/config/i386/t-mingw-w64 (working copy)
@@ -10,3 +10,9 @@
LIBGCC = stmp-multilib
INSTALL_LIBGCC = install-multilib
+
+SHLIB_IMPLIB = @shlib_base_n...@$(SHLIB_EXT).a
+MULTILIB_SONAME := gcc_s_$(EH_MODEL)-$(SHLIB_SOVERSION)$(SHLIB_EXT)
+
+SHLIB_SONAME = $$(if $$(shell $$(gcc_compile_bare) -xc -dD -E /dev/null |grep
-c __WIN64__ |sed -e 's/0//'),w64,w32)$(MULTILIB_SONAME)
+SHLIB_MKMAP_OPTS = -v pe_dll=$$(if $$(shell $$(gcc_compile_bare) -xc -dD -E
/dev/null |grep -c __WIN64__ |sed -e 's/0//'),w64,w32)$(MULTILIB_SONAME)
Index: gcc/config/i386/mingw-w64.h
===================================================================
--- gcc/config/i386/mingw-w64.h (revision 156923)
+++ gcc/config/i386/mingw-w64.h (working copy)
@@ -34,7 +34,20 @@
crtbegin.o%s"
/* Enable multilib. */
+#ifndef LIBGCC_EH_EXTN
+#error Include mingw32.h first.
+#endif
+#undef LIBGCC_SONAME
+#undef LIBGCJ_SONAME
+#ifdef WIN64
+#define LIBGCC_SONAME "w64gcc_s" LIBGCC_EH_EXTN "-1.dll"
+#define LIBGCJ_SONAME "w64ggcj" LIBGCC_EH_EXTN "-11.dll"
+#else
+#define LIBGCC_SONAME "w32gcc_s" LIBGCC_EH_EXTN "-1.dll"
+#define LIBGCJ_SONAME "w32ggcj" LIBGCC_EH_EXTN "-11.dll"
+#endif
+
#undef ASM_SPEC
#define ASM_SPEC "%{v:-v} %{n} %{T} %{Ym,*} %{Yd,*} \
%{Wa,*:%*} %{m32:--32} %{m64:--64}"
@@ -62,4 +75,5 @@
%{shared: --shared} %{mdll:--dll} \
%{static:-Bstatic} %{!static:-Bdynamic} \
%{shared|mdll: -e _dllmaincrtstar...@12 --enable-auto-image-base} \
- %(shared_libgcc_undefs)"
+ %(shared_libgcc_undefs) \
+ %{"SPEC_32": --dll-search-prefix=w32} %{"SPEC_64": --dll-search-prefix=w64}"
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
