Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 129598
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Toolchain Maintainers <toolchain@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Zephiris <zephiris@gmail.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 129598 depends on: Show dependency tree
Bug 129598 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2006-04-11 08:48 0000
Pardon if I'm rather new to all of this, I'll try to make it very clear.
The problem is that crossdev can generate a C cross-compiler for
i686-pc-mingw32 or i586-mingw32msvc adaquetely enough to produce apparently
correct code, but the name handling certainly isn't correct. I'm not sure if
this is necessarily more of a problem of portage (though binutils apparently
doesn't append .exe by default) with trying to emerge things for it, but for
instance, on my AMD64-based Gentoo installation, you can get files like this:
/usr/i586-mingw32msvc/lib64/libz.so.1.2.3: MS-DOS executable PE  for MS Windows
(DLL) (console) Intel 80386 32-bit
for: CHOST=i586-pc-mingw32 CFLAGS="-march=i586 -pipe -O3 -ffast-math"
ROOT=/usr/i586-mingw32msvc emerge zlib, which I'm told is the correct way to do
it.
Also, because base libraries and other things are already precompiled for
MingW, and it doesn't support glibc (or newlib, uclibc, et cetera), it means
that glibc and linux-headers aren't support for it, which means you can't
install a C++ cross-compiler, either. IIRC, static versions of libraries should
be libz.a, for instance, with shared linkable being libz.dll.a or just linking
against libz.dll.

I know conventional wisdom would be to download and use xmingw, but those are
somewhat out of date comparatively, the only 'additional' step should be
putting mingw-runtime and w32api tarballs into the target directory before
making the cross-compiler, which I can do easily, but using portage+crossdev, I
should reasonably be able to get a nicely working target (and emerge support
for compatible things) for cross-compilation with it. That's mostly compatible
with a large number of things, including the very libraries that I'd need to be
able to compile my projects with.

------- Comment #1 From SpanKY 2006-04-11 10:11:27 0000 -------
i mentioned this already but i have no urge to investigate how to integrate it

------- Comment #2 From Stefan Jones (RETIRED) 2006-04-11 11:40:58 0000 -------
Hi,

I'll see. Strangle I was just trying to update the dev-util/xmingw-*
ebuild today and yesterday.

I would first have to look into the crossdev process to see if it can
do the special things needed for xmingw

------- Comment #3 From SpanKY 2006-09-17 00:09:05 0000 -------
ive just gone ahead and done this myself ;)

# crossdev mingw32
--------------------------------------------------------------------------------
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   amd64
 * Target System:         mingw32
 * Stage:                 4 (C/C++ compiler)

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               w32api-[latest]
 * libc:                  mingw-runtime-[latest]

 * PORTDIR_OVERLAY:       /usr/local/portage
 * PORT_LOGDIR:           /var/log/portage
 * PKGDIR:                /usr/portage/packages/cross/mingw32
 * PORTAGE_TMPDIR:        /var/tmp/cross/mingw32
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -
 * Using dev-util/w32api from /usr/local/portage instead of /usr/portage
 * Using dev-util/mingw-runtime from /usr/local/portage instead of /usr/portage
 * Forcing the latest versions of binutils-config/gcc-config ...         [ ok ]
 * Log: /var/log/portage/cross-mingw32-binutils.log
 * Emerging cross-binutils ...                                           [ ok ]
 * Log: /var/log/portage/cross-mingw32-w32api-quick.log
 * Emerging cross-w32api-quick ...                                       [ ok ]
 * Log: /var/log/portage/cross-mingw32-mingw-runtime-headers.log
 * Emerging cross-mingw-runtime-headers ...                              [ ok ]
 * Log: /var/log/portage/cross-mingw32-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...                                         [ ok ]
 * Log: /var/log/portage/cross-mingw32-w32api.log
 * Emerging cross-w32api ...                                             [ ok ]
 * Log: /var/log/portage/cross-mingw32-mingw-runtime.log
 * Emerging cross-mingw-runtime ...                                      [ ok ]
 * Log: /var/log/portage/cross-mingw32-gcc-stage2.log
 * Emerging cross-gcc-stage2 ...                                         [ ok ]

# echo 'int main(){}' > test.c
# mingw32-gcc test.c 
# file a.exe 
a.exe: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit
# mingw32-gcc --version
mingw32-gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1)

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug