[Bug target/39947] New: Shared libgcc getting clobbered for multilib builds

[Bug target/39947] New: Shared libgcc getting clobbered for multilib builds

[10walls at gmail dot com]

Hello, 

Recently multilib capability was added to w64 mingw32 targets in gcc trunk.

I noticed that both 64bit and 32bit libgcc dlls install to <prefix>/bin. This
would be ok, for non-multilib native builds, but obviously not for multilib
cross compilers. For me, they are both named "libgcc_s_sjlj-1.dll".

I suggest something like libgcc_<version>_<excpetion>_<bitness>.dll, is that
ok?


-- 
           Summary: Shared libgcc getting clobbered for multilib builds
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: 10walls at gmail dot com
GCC target triplet: *-w64-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[10walls at gmail dot com]

------- Comment #1 from 10walls at gmail dot com  2009-04-28 15:39 -------
Hi,
some more info on the configured gcc:

built with:
../gcc-trunk/configure --host=i686-pc-mingw32 --build=i686-pc-mingw32
--target=x86_64-w64-mingw32 --enable-multilib --enable-64bit
--prefix=/mingw/w64_64 --with-sysroot=/mingw/w64_64
--enable-version-specific-runtime-libs --enable-shared --disable-nls
--with-dwarf --enable-fully-dynamic-string --enable-languages=c

gcc version 4.5.0 20090428 (experimental) (GCC)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[dannysmith at users dot sourceforge dot net]

------- Comment #2 from dannysmith at users dot sourceforge dot net  2009-04-29 07:29 -------
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc 

Danny


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dannysmith at users dot
                   |                            |sourceforge dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[ktietz at gcc dot gnu dot org]

------- Comment #3 from ktietz at gcc dot gnu dot org  2009-04-29 07:38 -------
(In reply to comment #2)
> The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
> libssp-x.dll, etc) that are built as part of gcc 
> Danny

That's correct. We have to find a way to install those binaries for multilib
builds into different locations, or we have to extend the DLL names by a target
key.
I would prefer here to use a different location, why not using in /bin target
specific directories? Something like bin/dll32 and bin/dll64?

Cheers,
Kai


-- 

ktietz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-04-29 07:38:25
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[jon_y at users dot sourceforge dot net]

------- Comment #4 from jon_y at users dot sourceforge dot net  2009-04-29 08:37 -------
(In reply to comment #3)
> (In reply to comment #2)
> > The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
> > libssp-x.dll, etc) that are built as part of gcc 
> > Danny
> 
> That's correct. We have to find a way to install those binaries for multilib
> builds into different locations, or we have to extend the DLL names by a target
> key.
> I would prefer here to use a different location, why not using in /bin target
> specific directories? Something like bin/dll32 and bin/dll64?
> 
> Cheers,
> Kai
> 

I would prefer a new naming scheme, that way, we don't need to change PATH (by
much) for the system to pick up the dlls.

btw, my libssp seems oddly placed.
<prefix>/lib/gcc/x86_64-w64-mingw32/bin/libssp-0.dll (64bit)
<prefix>/lib/gcc/x86_64-w64-mingw32/4.5.0/bin/libssp-0.dll (32bit)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[jon_y at users dot sourceforge dot net]

------- Comment #5 from jon_y at users dot sourceforge dot net  2010-01-24 07:59 -------
Ping,

We need to get this fixed ASAP. Probably involving the libtool devs as well. I
propose the following naming scheme.

libw64stdc++-6.dll (64bit mingw-w64)
libw32stdc++-6.dll (32bit mingw-w64)
libstdc++-6.dll (mingw.org)

libtool can check -dumpmachine for the vendor key.

Comments?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947

[Bug target/39947] Shared libgcc getting clobbered for multilib builds

[dmitrij dot ledkov at ubuntu dot com]

------- Comment #6 from dmitrij dot ledkov at ubuntu dot com  2010-07-06 18:58 -------
Yes please. I'm nearing completion of packaging co-installable w64 & w32
toolchains and I'm hitting a clash with this file now =) i'm wondering where to
shuffle it to.

I don't care about the naming but it should ideally be somewhere in version
specific location as mentioned before e.g.
<prefix>/lib/gcc/x86_64-w64-mingw32/4.5.0/bin/lib*.dll

Is there a stub patch to do this?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947