Web lists-archives.com

Re: [Mingw-users] Problems creating linkable file from MSVC .lib




Right.

I'm using the 32-bit mingw this mailing list is dedicated to, though I've tried all the same steps with the mingw-w64 project's 32-bit tools as well.

I found out a little bit more:

The driver I'm trying to link against is a really old one that's no longer supported (fun). I couldn't find the files online anywhere, but my employer happened to have a CD with the original drivers. There, I found that the manufacturer provided more files than I had: there was a set of .lib and .def files for each of MSVC and Borland C. The only difference I could make out in the def files was that the MSVC one has @XX after each symbol, while the Borland one does not. So:

    ncdActivateChannel             @23 // Borland
vs
    ncdActivateChannel@8           @23  //MSVC


Running dlltool using  the borland .def file gave me a .dll.a that I can link against (although I'm not sure why running it on the MSVC one with the -k option wouldn't, then?).

However I've run into trouble, whether I link against the dll.a that I created from that .def or just straight against the vcand32.dll: I'm having some issues with memory corruption when I call functions from this library that I don't have anywhere else. So, sometimes (but not always) my program will crash with a SIGSEGV when I call certain functions from this library. Adding std::cout statements to try and debug in some places fixes the seg fault, or moves it down a few lines. Sometimes adding an std::cout changes the valuable of the variable I'm printing, etc.

I spent the day trying to figure out if/where these problems might be caused by my own memory management problems but there's nothing. GDB doesn't tell me much of anything useful. Throwing the app through Dr. Memory only gives cryptic UNALLOCATED READ messages that trace through the library's functions into Windows DLLs or system calls like this (On a Windows XP machine, by the way):

Error #1: UNINITIALIZED READ: reading 0x0022f8ec-0x0022fa64 376 byte(s) within 0x0022f8ec-0x0022fa64
# 0 system call NtDeviceIoControlFile InputBuffer
# 1 ntdll.dll!ZwDeviceIoControlFile                            +0xb      (0x7c90d28a <ntdll.dll+0xd28a>)
# 2 KERNEL32.dll!DeviceIoControl                               +0x4b     (0x7c801675 <KERNEL32.dll+0x1675>)
# 3 vcand32.dll!ncdGetChannelMask                              +0x8e1    (0x005c2e86 <vcand32.dll+0x2e86>)
# 4 vcand32.dll!ncdGetChannelMask                              +0xef4    (0x005c3499 <vcand32.dll+0x3499>)
# 5 vcand32.dll!ncdGetChannelMask                              +0x2068   (0x005c460d <vcand32.dll+0x460d>)
# 6 vcand32.dll!ncdOpenDriver                                  +0x21     (0x005c12aa <vcand32.dll+0x12aa>)
# 7 VectorDriver::GetNumberOfChannels                           [source/candevice/windows/VectorDriver.cxx:33]
# 8 VectorDriver::GetDevices                                    [source/candevice/windows/VectorDriver.cxx:18]
# 9 CANDevice::EnumerateDevices                                 [source/candevice/CANDevice.cxx:82]
#10 CANDevice::CANDevice                                        [source/candevice/CANDevice.cxx:16]
#11 main                                                        [source/sidtest/sidtest.cxx:108]
Note: @0:00:04.110 in thread 3404


Am I right that this probably has to do with linkage problems with the MSVC vcand32.dll lib? Any ideas on a possible solution or should is this probably a library I'm not going to be able to link from gcc?

Chris



On Sat, Feb 20, 2016 at 12:56 PM, Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx> wrote:
On 20/02/16 17:00, Robert Miles wrote:
> One underscore at the beginning of a name usually indicates something
> within a library that is meant to be called only from within that library

No, it does no such thing; one underscore is prefixed to the unadorned
symbol name, the source, when compiled to PE-COFF format, so it is
perfectly normal for all symbols in a library to have at least one
initial underscore; the case to which you refer would have two such
initial underscores, for each symbol name within a library.

The issue is further compounded by Microsoft's practice of prefixing a
single underscore, at source level, to library functions which are
intended for public consumption, just because the associated functions
are not specified by the ISO-C standard; (this kind of infringes the
ISO-C stipulation that such symbols are reserved for use by the system
implementation, in the global file scope).  Such symbols will appear in
the library with two initial underscores, and are very much intended to
be called by user code...

> unless you understand the internals of that library well enough to
> understand the usually undocumented restrictions on calling it.

...so this caveat really isn't applicable in the MS-Windows world.

> The name of that library suggests that it was compiled to run in 32-bit
> mode.  MinGW is usually used in 64-bit mode instead.

Utter rubbish!  MinGW is a 32-bit compiler, intended for the 32-bit
MS-Windows platform.  If you think it's for 64-bit, you aren't using
MinGW; (you may be using mingw-w64, but that's an entirely different
product, from a different project, and not supported here).

--
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe