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++.