[Bug other/38294] Enable multilib support for mingw

[Bug other/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

-- 

nightstrike at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


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

[Bug other/38294] New: Enable multilib support for mingw

[nightstrike at gmail dot com]

Now that we have a viable header set and libraries for x86_64-pc-mingw32, we
are able to support multilib.  This needs to be enabled.


-- 
           Summary: Enable multilib support for mingw
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nightstrike at gmail dot com
GCC target triplet: x86_64-*-mingw32


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

[Bug other/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #1 from nightstrike at gmail dot com  2008-11-27 17:43 -------
Created an attachment (id=16785)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16785&action=view)
My first crack at enabling the support


-- 


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #2 from nightstrike at gmail dot com  2008-12-08 07:48 -------
Created an attachment (id=16849)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16849&action=view)
Second attempt

This gets us further along


-- 

nightstrike at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16785|0                           |1
        is obsolete|                            |


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

------- Comment #3 from ktietz at gcc dot gnu dot org  2008-12-08 20:16 -------
>From my point of view this patch seems to be ok.
Multilib is just enabled for 64-bit default target, what makes sende at the
moment. Just about the point of multilib library specifier, I am not sure.
Shouldn't it separated by comman.


-- 

ktietz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ktietz at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-08 20:16:54
               date|                            |


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #4 from nightstrike at gmail dot com  2008-12-13 21:19 -------
As per jakub, it is space separated.


-- 


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

------- Comment #5 from ktietz at gcc dot gnu dot org  2008-12-13 21:46 -------
Reasoned by the fact, that this patch will solve our build failures for w64, it
is really more to be treated as regression.

NightStrike, when all tests you are doing at the moment are passing, I'll sent
it tomorrow to gcc-patches.

Danny is this ok for you?


-- 

ktietz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |4.4.0


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #6 from nightstrike at gmail dot com  2008-12-13 21:59 -------
Created an attachment (id=16906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view)
Third attempt

There were a few lines in t-mingw32 that were commented out and shouldn't have
been there.  Fixed in this patch.


-- 

nightstrike at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16849|0                           |1
        is obsolete|                            |


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #7 from nightstrike at gmail dot com  2008-12-13 23:01 -------
Tested and verified on win64


-- 


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #8 from nightstrike at gmail dot com  2008-12-14 00:11 -------
To complete this patch, we need to make multilib not be the default.


-- 


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

[Bug target/38294] Enable multilib support for mingw

[dannysmith at users dot sourceforge dot net]

------- Comment #9 from dannysmith at users dot sourceforge dot net  2008-12-14 05:54 -------
(In reply to comment #5)
> Reasoned by the fact, that this patch will solve our build failures for w64, it
> is really more to be treated as regression.
> 
> NightStrike, when all tests you are doing at the moment are passing, I'll sent
> it tomorrow to gcc-patches.
> 
> Danny is this ok for you?
> 
I would prefer that this be left until 4.5. I don't understand how failing to
add a new feature is now a regression.

(In reply to comment #6)
> Created an attachment (id=16906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view) [edit]
> Third attempt
> 
> There were a few lines in t-mingw32 that were commented out and shouldn't have
> been there.  Fixed in this patch.


Please also remove this unnecessary change in mingw32.h

+#if TARGET_64BIT_DEFAULT
 #define STANDARD_INCLUDE_DIR "/mingw/include"
+#else
+#define STANDARD_INCLUDE_DIR "/mingw/include"
 #endif

Nightstrike,  have you completed FSF copyright assignment formality

Danny


-- 


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

------- Comment #10 from ktietz at gcc dot gnu dot org  2008-12-14 07:50 -------
(In reply to comment #9)
> (In reply to comment #5)
> > Reasoned by the fact, that this patch will solve our build failures for w64, it
> > is really more to be treated as regression.
> > 
> > NightStrike, when all tests you are doing at the moment are passing, I'll sent
> > it tomorrow to gcc-patches.
> > 
> > Danny is this ok for you?
> > 
> I would prefer that this be left until 4.5. I don't understand how failing to
> add a new feature is now a regression.

Yes, this bug is reasoned by preparations to support multilib in w64 crt. Now
we generate the target specific object files for 64-bit into the 'lib64'
folder. This reasoned the problem we talking about.
In the past we put our object (and library) files into <target-triplet>/lib
folder, which has hidden the problem.
But for me it is ok to fix this for 4.5 (beside we need to work-a-round this
for version before 4.5).

> (In reply to comment #6)
> > Created an attachment (id=16906)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view) [edit]
> > Third attempt
> > 
> > There were a few lines in t-mingw32 that were commented out and shouldn't have
> > been there.  Fixed in this patch.
> 
> 
> Please also remove this unnecessary change in mingw32.h
> 
> +#if TARGET_64BIT_DEFAULT
>  #define STANDARD_INCLUDE_DIR "/mingw/include"
> +#else
> +#define STANDARD_INCLUDE_DIR "/mingw/include"
>  #endif

Yes, just make out of this '#define STANDARD_INCLUDE_DIR "/mingw/include"'

Kai


-- 


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

[Bug target/38294] Enable multilib support for mingw

[nightstrike at gmail dot com]

------- Comment #11 from nightstrike at gmail dot com  2009-02-06 04:21 -------
Created an attachment (id=17259)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17259&action=view)
Kai's attempt

This patch has a few caveats:

You can't use the winsup link hack to work around the issue that Corinna
injected, so you can't build libstdc++, so you can't build g++

Also, the lib directories are all fubared because of ld not allowing custom
default lib paths (it's hard coded to use /root/target/lib):
1) x86_64-pc-mingw32/lib remains the place for 64-bit mingw objects
and libraries
2) x86_64-pc-mingw32/lib64 is a link to x86_64-pc-mingw32/lib
3) x86_64-pc-mingw32/lib32 is the place for 32-bit mingw


-- 


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

------- Comment #12 from ktietz at gcc dot gnu dot org  2009-08-31 19:49 -------
(In reply to comment #11)
> Created an attachment (id=17259)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17259&action=view) [edit]
> Kai's attempt
> 
> This patch has a few caveats:
> 
> You can't use the winsup link hack to work around the issue that Corinna
> injected, so you can't build libstdc++, so you can't build g++

Why that? winsup has to point in our case always to sysroot.

> Also, the lib directories are all fubared because of ld not allowing custom
> default lib paths (it's hard coded to use /root/target/lib):
> 1) x86_64-pc-mingw32/lib remains the place for 64-bit mingw objects
> and libraries
And this library remains for ld's sake here.

> 2) x86_64-pc-mingw32/lib64 is a link to x86_64-pc-mingw32/lib
For cross-compiler with unix environment no issue, for native a junction point
is necessary. We need not to link mingw to x86_64-pc-mingw32 folder, it can be
a physical folder. Then headers and libraries can go also directly into
mingw/include and mingw/(lib/lib32).
> 3) x86_64-pc-mingw32/lib32 is the place for 32-bit mingw
And?


-- 


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

[Bug target/38294] Enable multilib support for mingw

[ktietz at gcc dot gnu dot org]

------- Comment #13 from ktietz at gcc dot gnu dot org  2009-08-31 19:52 -------
As the change is already applied to head, I close this.


-- 

ktietz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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