From: Vincent T. <vt...@un...> - 2008-09-15 06:16:42
|
Hey i'm cross-compiling windowss programs on linux, using mingw32msvc (I have an ubuntu and i installed the mingw package) I'm using _IID_IPersistFile (for creation / reading of .lnk files). With mingw on Windows, no problem, it's in libuuid.a. But with mingw32msvc, it is not in libuuid.a, and I even do not find it in any other static lib. My first question: is it the correct mailing list for questions about cross-compilation with mingw32msvc ? My second and last question: if yes, is it a bug or should I link against another static lib (which is not in /usr/i586-mingw32msvc/lib) ? thank you Vincent Torri |
From: Brian D. <br...@de...> - 2008-09-15 07:07:14
|
Vincent Torri wrote: > I'm using _IID_IPersistFile (for creation / reading of .lnk files). > With mingw on Windows, no problem, it's in libuuid.a. But with > mingw32msvc, it is not in libuuid.a, and I even do not find it in any > other static lib. It looks like it's there to me: $ wget -q http://http.us.debian.org/debian/pool/main/m/mingw32-runtime/mingw32-runtime_3.9-4_all.deb $ ar x mingw32-runtime_3.9-4_all.deb $ tar zxf data.tar.gz $ nm -AP usr/i586-mingw32msvc/lib/libuuid.a | grep _IID_IPersistFile usr/i586-mingw32msvc/lib/libuuid.a[uuid.o]: _IID_IPersistFile R 000006c0 Are you sure there's not some other difference between the two environments, such as the ordering of -lfoo arguments on the link command line? > My first question: is it the correct mailing list for questions about > cross-compilation with mingw32msvc ? No, you should report problems with Debian's packages to the Debian bug tracker: <http://bugs.debian.org/src:mingw32-runtime>. This list is hesitant to support other projects's packages, especially when MinGW provides its own cross-builder script. Brian |
From: Vincent T. <vt...@un...> - 2008-09-15 07:31:46
|
On Mon, 15 Sep 2008, Brian Dessent wrote: > Vincent Torri wrote: > >> I'm using _IID_IPersistFile (for creation / reading of .lnk files). >> With mingw on Windows, no problem, it's in libuuid.a. But with >> mingw32msvc, it is not in libuuid.a, and I even do not find it in any >> other static lib. > > It looks like it's there to me: > $ nm -AP usr/i586-mingw32msvc/lib/libuuid.a | grep _IID_IPersistFile > usr/i586-mingw32msvc/lib/libuuid.a[uuid.o]: _IID_IPersistFile R 000006c0 oh, I use -C for nm (i usually do that) and nothing was shown. I also used /usr/bin/i586-mingw32msvc-nm instead of my linux nm. With -AP, it is indeed shown. > Are you sure there's not some other difference between the two > environments, such as the ordering of -lfoo arguments on the link > command line? i played a bit with the order and now the undefined has gone. It remains a: "*** Warning: linker path does not have real file for library -luuid. etc..." i passed -no-undefined to the linker but it seems that libtool is still not happy :/ Hence no dll is built. >> My first question: is it the correct mailing list for questions about >> cross-compilation with mingw32msvc ? > > No, you should report problems with Debian's packages to the Debian bug > tracker: <http://bugs.debian.org/src:mingw32-runtime>. This list is > hesitant to support other projects's packages, especially when MinGW > provides its own cross-builder script. ok for the ML. talking about cross-compilation provided with mingw, the doc about setting it is too complicated. I have looked at http://mingw.org/node/31 you have indeed, after the download of the different files 3 paragraphs about gcc 4.* and updated scripts (yes, several updates...). The user (me, for example...) is asking himself: "what should I do ???" if mingw provides a way to cross-compile mingw progs on linux, only one "official" way should be given (like gcc ports as a guy ported different versions of gcc 4.3 for mingw, but no official 4.3 port (well, there is an alpha of 4.3.0) is supported by mingw right now. also, in that page, there are some missing links. I have: Get [this shell-Script] Get [this patch to math.h] without links thanks Vincent Torri |
From: Brian D. <br...@de...> - 2008-09-15 12:02:10
|
Vincent Torri wrote: > oh, I use -C for nm (i usually do that) and nothing was shown. I also used With -C it's going to omit the leading _ from the symbol as that's only part of the assembler-name of the symbol and not the source-level name. You'd have to grep for 'IID_IPersistFile' if you want to use -C. > i played a bit with the order and now the undefined has gone. It remains > a: > > "*** Warning: linker path does not have real file for library -luuid. > etc..." > > i passed -no-undefined to the linker but it seems that libtool is still > not happy :/ Hence no dll is built. That's now squarely into libtool territory and has nothing directly to do with the compiler/linker any more; you should move this onto the libtool list. Though I think this is going to be a problem in that libuuid.a is special in that unlike the rest of w32api it's *not* an import library for a DLL, but rather it's an actual static library that contains pure data items. libtool will not allow you to link against a static library when creating a shared library, because it can't do this portably[1]. If that is what is happening, you'll have to sneak the option past libtool, e.g. -Wl,-luuid. Brian [1] Before anyone comes to the conclusion that libtool is making life difficult by catering to some weird oddity operating system, consider that every flavor of Linux except 32 bit IA32 disallows non-PIC code in shared libraries. Static libs are typically not built with PIC code -- and if one were, libtool would have no way of checking -- so this means they can't be used when linking a shared library. |
From: Keith M. <kei...@us...> - 2008-09-15 16:19:35
|
On Monday 15 September 2008 08:31:36 Vincent Torri wrote: > talking about cross-compilation provided with mingw, the doc about > setting it is too complicated. I have looked at > http://mingw.org/node/31 Well, that was just raw phpWiki format text, copied from the old to the new wiki, without reformatting. Don't use it as a reference; in fact, don't use the old wiki content either, because it's all stale and obsolete. > you have indeed, after the download of the different files 3 > paragraphs about gcc 4.* and updated scripts (yes, several > updates...). The user (me, for example...) is asking himself: "what > should I do ???" I have no intention of supporting GCC-4 as a Linux-MinGW cross, until after such time as Aaron is ready to declare native 4.3 stable. The only version officially supported is GCC-3.4.5. References t6 GCC-4 had been added as comments to the old wiki content, and are in no way sanctioned by the maintainer. (This is the downside of wikis; while it's nice to have the community help with site maintenance, it also allows unwanted content to proliferate, where it may not be best placed). > if mingw provides a way to cross-compile mingw progs on linux, only > one "official" way should be given There is, and always has been, only one official way. I've been meaning to clean up that wiki page for some time; it's done now: http://www.mingw.org/wiki/LinuxCrossMinGW > (like gcc ports as a guy ported > different versions of gcc 4.3 for mingw, but no official 4.3 port > (well, there is an alpha of 4.3.0) is supported by mingw right now. Only as a native technology preview, alpha status, and not yet stable; no way will I extend the support to cross compiling, until the native version is formally released as stable. Regards, Keith. |
From: Vincent T. <vt...@un...> - 2008-09-15 19:48:38
|
On Tue, 16 Sep 2008, Keith Marshall wrote: > On Monday 15 September 2008 08:31:36 Vincent Torri wrote: >> talking about cross-compilation provided with mingw, the doc about >> setting it is too complicated. I have looked at >> http://mingw.org/node/31 > placed). > > There is, and always has been, only one official way. I've been meaning > to clean up that wiki page for some time; it's done now: > http://www.mingw.org/wiki/LinuxCrossMinGW it's quite nicer, now. Thanks. Vincent Torri |