Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=2657074
By: aaronwl
Sort of.
Most of the DirectX libraries are more than just import libraries. Import libraries
themself are not very sophisticated creatures, and quite hard to get wrong.
On the other hand, the other code in the DX libraries uses relatively sophisticated
features that are not yet fully supported by GNU binutils, mingwrt, and other
tools.
Also, there are doubtless still quite a few bugs in the tools MinGW uses, that
may very well affect things like import libraries. If you have any specific
information about these, these should be reported.
As far as getting DX to work, in particular, everything from the latest DXSDK
does work with MinGW. However, it almost certainly will need some modification,
adjustment, or other hacking. At this time, production DX builds that use D3D
and D3DX, for example, will definitely not 'just work' as on MSVC. Specific
questions about getting it work are always welcomed, of course.
Its hard to really say much more without being more specific. Hope this helps,
Aaron W. LaFramboise
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=7134

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=2657042
By: sevalecan
Well I did hear a while back that the only difference between msvc's and mingw's
.lib/.a formats were the dll exports. Maybe this isnt true anymore(or never
was) but then why did someone go through all of the trouble of getting .a's
of directX for mingw. Other people I've spoken to seem to agree with me, I'm
not sure whether any of them have ever checked it out though. But are you saying
that it should be possible for me to just use the .lib's with directx instead
of converting them?
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=7134

Luke Dunstan wrote:
> You may be right that binutils needs to have special handling for symbols
> beginning with '?' but surely this is the least of his problems? When the
> client code (sample.cpp) is compiled with GCC then it references symbols
> using GCC name mangling which is incompatible with MSVC (use nm on sample.o
> to see). If the interface of this DLL is compatible with plain C then the
> solution is to declare the functions as extern "C" when building both the
> DLL and EXE, but if not then the interface would need to be changed to allow
> mixing of compilers.
Well I have no idea what he's doing. I'm assuming he has a basic idea
of the compatiblity limits, and he hasn't showed any other errors, so I
have no idea if he has any other sorts of problems. If he is having
errors of the sort he's mentioned, theres a good chance he's already
gotten past possible ABI problems.
Having said that, silly errors like these happen in all sorts of
situations where the link might almost-work otherwise. It is quite
common for libraries which appear to export C interfaces to have C++
lurking internally. Since maintainers have generally made decisions
that make the GNU development dependent on GNU binutils ld, perhaps the
GNU tools have some sort of obligation to have a basic compatibility
with MSVC in cases like these, as it is not possible to use MS LINK instead.
There have been a few other small almost-link MSVC compatibility
problems in the past. Some things have already been fixed. My recent
weak symbol patches will fix one of them. Some code I plan on
submitting regarding initialization should fix some others. With any
luck, there really won't be too many other reasons for this basic
compatibility not to work after that.
Too bad about the incompatible C++ ABIs, though.
Aaron W. LaFramboise

----- Original Message -----
From: "Aaron W. LaFramboise" <aaron77thyme@...>
To: <mingw-users@...>
Sent: Friday, July 09, 2004 5:11 AM
Subject: Re: [Mingw-users] Using MSVC DLLs
> Marco Grubert wrote:
> > This is true for all the functions exported by the DLL- none can be
> > resolved. Even though they are listed in libadll.a (but with that added
> > underscore).
> > Any suggestions ?
>
> This is a binutils bug (sort of).
>
> I have a patch for this to binutils pending someone noticing it. :)
> When I submit another dlltool patch soon, I'm going to ping it.
>
> As a slightly longer explanation, all C symbols in PECOFF on Win32 are
> prefixed with a _. The traditional reason this is done is to prevent
> conflicts between C identifiers and the identifiers of the underlying
> compiler machinery. MSVC authors decided that C++ symbols should go
> into a separate namespace (although prepending the mangled symbols with
> a double-underscore would probably have been sufficient for practical
> purposes), and so they decided a ? prefix should be used rather than the
> C _ prefix, so that conflicts were not possible. Unfortunately it
> requires the object tools to know about it, and as no standard (that I
> am familiar with) specifies this, binutils doesn't do it.
>
> In the mean time, if you need this feature to get your project working,
> you'll need to recompile binutils with this patch. You should be able
> to do this within MSYS. The patch is at:
> http://sources.redhat.com/ml/binutils/2004-06/msg00500.html
>
> Hope this helps.
>
> Aaron W. LaFramboise
You may be right that binutils needs to have special handling for symbols
beginning with '?' but surely this is the least of his problems? When the
client code (sample.cpp) is compiled with GCC then it references symbols
using GCC name mangling which is incompatible with MSVC (use nm on sample.o
to see). If the interface of this DLL is compatible with plain C then the
solution is to declare the functions as extern "C" when building both the
DLL and EXE, but if not then the interface would need to be changed to allow
mixing of compilers.
http://www.mingw.org/MinGWiki/index.php/MixingCompilers
Luke

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details