From: <fk...@go...> - 2011-04-23 07:35:18
|
Hi, My 32 bit mingw cross compiler works, but the 64 version fails when linking system libraries. I've set up a x86_64-pc-mingw32 64 bit cross compiler (under gentoo linux with paludis packet manager). I can compile 64 bit code, however, linking fails: /usr/lib/gcc/x86_64-pc-mingw32/4.5.2/../../../../x86_64-pc-mingw32/lib/dllcrt2.o:crtdll.c:(.text+0xb): undefined reference to `malloc' (... and a lot more) When I lookup dllcrt2.o from my existing 32 bit cross compiler, then 'malloc' has an underscore, but the 64 bit version of dllcrt2.o does NOT have one. I have read that some calling convention has changed. However, what are the steps to solve this then? FYI: I am using mingw64-runtime-20101003, binutils-2.21.51.0.8, gcc-4.5.2. Felix |
From: JonY <jo...@us...> - 2011-04-23 07:49:18
Attachments:
signature.asc
0xED74C077.asc
|
On 4/23/2011 15:34, fk...@go... wrote: > Hi, > > My 32 bit mingw cross compiler works, but the 64 version > fails when linking system libraries. > > I've set up a x86_64-pc-mingw32 64 bit cross compiler (under > gentoo linux with paludis packet manager). > > I can compile 64 bit code, however, linking fails: > > /usr/lib/gcc/x86_64-pc-mingw32/4.5.2/../../../../x86_64-pc-mingw32/lib/dllcrt2.o:crtdll.c:(.text+0xb): > undefined reference to `malloc' > (... and a lot more) > > When I lookup dllcrt2.o from my existing 32 bit cross > compiler, then 'malloc' has an underscore, but the 64 bit > version of dllcrt2.o does NOT have one. > > I have read that some calling convention has changed. > However, what are the steps to solve this then? > > FYI: I am using mingw64-runtime-20101003, > binutils-2.21.51.0.8, gcc-4.5.2. > > Felix > > -- Adding to mingw-w64 public list -- Hi, The underscore part is correct, win64 symbols do not have underscore prefixes like win32 symbols. Yes, call convention changed, GCC 4.5.0, 4.4.x and earlier will use underscores regardless of win32/win64 target. It was a design decision mistake. GCC 4.5.1 and later including the 4.6.x series will use underscore prefix only for win32. Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the latter is only used for compatibility, I'd admit there isn't much compatibility with 32bit mingw. |
From: Keith M. <kei...@us...> - 2011-04-23 08:43:00
|
On 23/04/11 08:48, JonY wrote: > Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the > latter is only used for compatibility, I'd admit there isn't much > compatibility with 32bit mingw. What is 64-bit mingw32? Why do the w64 guys continue to promulgate this insanity? An OSTYPE of "mingw32" *should* refer *exclusively* to 32-bit windows. Perverting it to represent either 32-bit or 64-bit is both asinine and confusing; an OSTYPE of "mingw64" should be registered with the "config" guys, and deployed consistently, to clear up this absurdity. -- Regards, Keith. |
From: Kai T. <kti...@go...> - 2011-04-23 10:02:39
|
2011/4/23 Keith Marshall <kei...@us...>: > On 23/04/11 08:48, JonY wrote: >> Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the >> latter is only used for compatibility, I'd admit there isn't much >> compatibility with 32bit mingw. > > What is 64-bit mingw32? > > Why do the w64 guys continue to promulgate this insanity? An OSTYPE of > "mingw32" *should* refer *exclusively* to 32-bit windows. Perverting it > to represent either 32-bit or 64-bit is both asinine and confusing; an > OSTYPE of "mingw64" should be registered with the "config" guys, and > deployed consistently, to clear up this absurdity. AFAIR did we discussed that already and insane is the naming of bit-ness in OSTYPE itself. The bitness in architecture type is enough, no need to repeat it in OS-part. The OS is for 32-bit and 64-bit just Windows. I admit that the choose of mingw as OS part might be misleading, as windows would be more correct. Are you familiar with naming schema for linux as example, or other *nix targets, which having 32-bit and 64-bit flavors? I assume no, as otherwise you wouldn't raise this discussion again and again. A linux remains a (i?86|x86_64|what-ever-architecture)-pc-linux, Same is true for for any other target. So this 32 post-fix for architecture is insane, and I will take care for 4.7 that it becomes even in configure superflöus (thanks for the reminder). Regards, Kai |
From: Charles W. <cwi...@us...> - 2011-04-23 13:25:01
|
On 4/23/2011 4:42 AM, Keith Marshall wrote: > On 23/04/11 08:48, JonY wrote: >> Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the >> latter is only used for compatibility, I'd admit there isn't much >> compatibility with 32bit mingw. > > What is 64-bit mingw32? > > Why do the w64 guys continue to promulgate this insanity? Because *we* were too shortsighted, which pushing patches upstream over the years, to do things like *-*-mingw* ) .... and instead we did *-*-mingw32 ) ... Ditto for the various #ifdefs. If we'd been smart, our compiler would have #defined __MINGW__ and __MINGW32__, and MOST of our patches would have been conditioned on the former instead of the latter. Anyway, you're not the first to point out that the current situation with mingw64's triple is...imperfect. IIRC there was a big discussion thread on gcc-patches a year or two ago. > An OSTYPE of > "mingw32" *should* refer *exclusively* to 32-bit windows. Perverting it > to represent either 32-bit or 64-bit is both asinine and confusing; an > OSTYPE of "mingw64" should be registered with the "config" guys, and > deployed consistently, to clear up this absurdity. That horse has left the barn, and besides, it's not fkater's fault, or his problem. -- Chuck |
From: NightStrike <nig...@gm...> - 2011-04-26 12:29:00
|
On Sat, Apr 23, 2011 at 4:42 AM, Keith Marshall <kei...@us...> wrote: > On 23/04/11 08:48, JonY wrote: >> Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the >> latter is only used for compatibility, I'd admit there isn't much >> compatibility with 32bit mingw. > > What is 64-bit mingw32? > > Why do the w64 guys continue to promulgate this insanity? An OSTYPE of > "mingw32" *should* refer *exclusively* to 32-bit windows. Perverting it > to represent either 32-bit or 64-bit is both asinine and confusing; an > OSTYPE of "mingw64" should be registered with the "config" guys, and > deployed consistently, to clear up this absurdity. To quote your oft-touted adage in answer to your question of "Why?", "Go read the mailing list. It's been explained there countless times." |
From: <fk...@go...> - 2011-04-23 09:49:44
|
Hi JonY, JonY: > The underscore part is correct, win64 symbols do not have underscore > prefixes like win32 symbols. > > Yes, call convention changed, GCC 4.5.0, 4.4.x and earlier will use > underscores regardless of win32/win64 target. It was a design decision > mistake. GCC 4.5.1 and later including the 4.6.x series will use > underscore prefix only for win32. Good to know, however, I do use gcc-4.5.2 (see the OP). So, what might be the problem then? Is there some missing config flag or anything? I am not an expert in these configuring issues. > Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the > latter is only used for compatibility, I'd admit there isn't much > compatibility with 32bit mingw. You say "btw", so, let me ask: Do you mean that could be the reason for the underscore issue? Thanks a lot! Felix |
From: Kai T. <kti...@go...> - 2011-04-23 09:55:33
|
2011/4/23 fk...@go... <fk...@go...>: > Hi JonY, > > JonY: > >> The underscore part is correct, win64 symbols do not have underscore >> prefixes like win32 symbols. >> >> Yes, call convention changed, GCC 4.5.0, 4.4.x and earlier will use >> underscores regardless of win32/win64 target. It was a design decision >> mistake. GCC 4.5.1 and later including the 4.6.x series will use >> underscore prefix only for win32. > > Good to know, however, I do use gcc-4.5.2 (see the OP). So, > what might be the problem then? Is there some missing config > flag or anything? I am not an expert in these configuring > issues. > > >> Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the >> latter is only used for compatibility, I'd admit there isn't much >> compatibility with 32bit mingw. > > You say "btw", so, let me ask: Do you mean that could be the > reason for the underscore issue? > > Thanks a lot! > Felix Well, issue is here that you might mixed up libraries/objects build with gcc before 4.5.1 with libraries/objects build with newer gcc version. Other issue might be that you are using newer gcc with older binutils version. This might be also a cause here. Regards, Kai |
From: <fk...@go...> - 2011-04-23 09:57:12
|
Keith Marshall: > On 23/04/11 08:48, JonY wrote: > > Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the > > latter is only used for compatibility, I'd admit there isn't much > > compatibility with 32bit mingw. > > What is 64-bit mingw32? > > Why do the w64 guys continue to promulgate this insanity? An OSTYPE of > "mingw32" *should* refer *exclusively* to 32-bit windows. Perverting it > to represent either 32-bit or 64-bit is both asinine and confusing; an > OSTYPE of "mingw64" should be registered with the "config" guys, and > deployed consistently, to clear up this absurdity. I am not at all a mingw developer and I personally agree. However, just my 2p: For all windows targets, regardless if 32 or 64 bit, GCC defines WIN32 = 1 implicitly. In case of 64 bit, _WIN64 is defined additionally. Maybe this was a motivation. BTW: This is not the only confusing thing. There is amd64 used for intel as well ... Felix |
From: Kai T. <kti...@go...> - 2011-04-23 10:10:38
|
2011/4/23 fk...@go... <fk...@go...>: > Keith Marshall: > >> On 23/04/11 08:48, JonY wrote: >> > Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the >> > latter is only used for compatibility, I'd admit there isn't much >> > compatibility with 32bit mingw. >> >> What is 64-bit mingw32? >> >> Why do the w64 guys continue to promulgate this insanity? An OSTYPE of >> "mingw32" *should* refer *exclusively* to 32-bit windows. Perverting it >> to represent either 32-bit or 64-bit is both asinine and confusing; an >> OSTYPE of "mingw64" should be registered with the "config" guys, and >> deployed consistently, to clear up this absurdity. > > I am not at all a mingw developer and I personally agree. > However, just my 2p: > > For all windows targets, regardless if 32 or 64 bit, GCC > defines WIN32 = 1 implicitly. In case of 64 bit, _WIN64 is > defined additionally. Maybe this was a motivation. Sorry to destroy here you theory, but for 64-bit Windows target _WIN32 and _WIN64 are to be defined. See here msdn and predefined macros of VC for more details. The cause for this is that 64-bit uses the same Win32 API. So the _WIN64 just indicates that you are building for 64-bit. > BTW: This is not the only confusing thing. There is amd64 > used for intel as well ... There are three different names for the same thing: amd64, x86_64, and x64. See for more details http://de.wikipedia.org/wiki/AMD64 page. It describes some of this weirdness. Regards, Kai |
From: JonY <jo...@us...> - 2011-04-23 10:54:25
Attachments:
signature.asc
0xED74C077.asc
|
On 4/23/2011 17:49, fk...@go... wrote: > Hi JonY, > > JonY: > >> The underscore part is correct, win64 symbols do not have underscore >> prefixes like win32 symbols. >> >> Yes, call convention changed, GCC 4.5.0, 4.4.x and earlier will use >> underscores regardless of win32/win64 target. It was a design decision >> mistake. GCC 4.5.1 and later including the 4.6.x series will use >> underscore prefix only for win32. > > Good to know, however, I do use gcc-4.5.2 (see the OP). So, > what might be the problem then? Is there some missing config > flag or anything? I am not an expert in these configuring > issues. > > Switching from an earlier version, you will experience a break in ABI, so you'll need to recompile ALL your libraries with the new compiler to make sure they work. There isn't a problem on your end, the compiler ABI changed, so you shouldn't be mixing new and old libraries. >> Btw, please use x86_64-w64-mingw32 instead of x86_64-pc-mingw32, the >> latter is only used for compatibility, I'd admit there isn't much >> compatibility with 32bit mingw. > > You say "btw", so, let me ask: Do you mean that could be the > reason for the underscore issue? > > Thanks a lot! > Felix > > Not really, but in addition to what Kai said, some features are only enabled when using the "w64" vendor key. It doesn't really affect the underscore issue. |
From: <fk...@go...> - 2011-04-23 15:27:20
|
JonY: > Switching from an earlier version, you will experience a break in ABI, > so you'll need to recompile ALL your libraries with the new compiler to > make sure they work. > > There isn't a problem on your end, the compiler ABI changed, so you > shouldn't be mixing new and old libraries. Hooray... I've just seen my little proggy saying "hello ming64 world" on win7, and pointers of 64 bit size... It is not completely clear to me why it works now. FYI, what I did: * removed all x86_64-pc-mingw32 things * changed to x86_64-w64-mingw32 * installed mingw64-runtime (headers only) * compiled binutils and gcc (minimal) * compiled mingw64-runtime,binutils,gcc Thank's to all for the support! Felix |