5 messages in com.mysql.lists.plusplusRe: Building MySQL++ 2.1.1 with MinGW| From | Sent On | Attachments |
|---|---|---|
| Joel Fielder | 29 Jun 2006 01:48 | |
| Warren Young | 29 Jun 2006 17:40 | |
| Carlos Flores | 30 Jun 2006 07:30 | |
| Joel Fielder | 03 Jul 2006 02:11 | |
| Warren Young | 05 Jul 2006 07:27 |
| Subject: | Re: Building MySQL++ 2.1.1 with MinGW |
|---|---|
| From: | Carlos Flores (caf...@gmail.com) |
| Date: | 06/30/2006 07:30:35 AM |
| List: | com.mysql.lists.plusplus |
Warren Young escribió:
Sigh....making the reverse change is exactly what _did_ work for me. It was the way you're describing in earlier versions of MySQL++, and we got more complaints about build failures on MinGW then. Are the MinGW developers flip-flopping on this issue, or fixing long-standing compatibility issues once and for all, or what?
Actually it is one of the mayor issues of mingw's ld, but it seems that next stable of binutils release will fix many of this problems, but as I have repeated many times, when many of the --enable-auto-import errors appear, all you have to do is to add --enable-runtime-pseudo-reloc to linker flags, and everything will build fine.
In fact it is a design feature of mingw's ld that makes him able to behave like *nix linkers on windows, and it allows many *nix (mostly linux) code to be imported almost as it is to win32, and it adds the capability to direct linking against a dll, so it was an almost intentional bug, but it bothered so many people (check gtkmm's bugzilla or libpqxx's bug tracker, not sure about that last) that it needed to be corrected, and it seems that when gcc 4.0 finally arrives to win32/win64 it will be completly fixed.
It also seems that you're using tools that aren't officially released yet, so I wonder if I'm going to have to recommend that all MinGW users do the same for it to work this new way?
It works with all mingw's gcc releases and mingw's binutils releases, the only change on them where binary compatibility (code compiled by 3.4.5 is not compatible with 3.4.4 an previous, only C++, and allows propagation of exceptions through dlls on win32).
Interesting. I don't understand why you have to do that to classes, since the class proper isn't part of the DLL's interface; only its member functions are.
Anyway you can add the MYSQLPP_EXPORT to the functions directly and check if it works.
Do you know if this works with VC++? If it breaks that, I won't be applying it.
It is perfectly legal for VC++.