Problems creating linkable file from MSVC .lib

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems creating linkable file from MSVC .lib

Chris-2
I'm trying to link my mingw gcc project to two hardware driver libraries presumably compiled with MSVC.

The first one worked fine following the guide on the mingw site... I used reimp to create a .def file from the .lib, then dlltool to create the .a file I imported into my project.

The second one is yet to work for me. If I run reimp on the .lib, it produces no output (though it pulls in/creates a 1-byte .dll in the working directory). If I run reimp -S on the lib, though, it does list all of the symbols.

Next I tried using both gendef and pexports to create a def file from the lib. Either way looks pretty much the same. Here's the output from gendef, truncated: 

;
; Definition file of vcand32.dll
; Automatic generated by gendef
; written by Kai Tietz 2008
;
LIBRARY "vcand32.dll"
EXPORTS
ncdOpenDriver
ncdGetDriverConfig@8
ncdOpenPort@24
ncdSetChannelMode@16
ncdSetChannelOutput@12
ncdSetChannelTransceiver@20
ncdSetChannelParams@20
ncdSetChannelParamsC200@16
ncdSetChannelBitrate@12
ncdSetChannelAcceptance@12
ncdSetTimerRate@8
...

Then I use dlltool to create a .a file from that and the original dll. The problem is, no matter what options I use to create the .a file, the linker gives an error like "undefined reference to `_imp__ncdOpenDriver'" for every call. Notice there is one underscore before imp and two after. If I run `nm libvcand32.a | grep imp` I get lines like this:  

00000000 I __imp__ncdOpenPort
00000000 I __imp__ncdOpenDriver
00000000 I __imp__ncdGetState
00000000 I __imp__ncdGetReceiveQueueLevel
00000000 I __imp__ncdGetEventString
00000000 I __imp__ncdGetErrorString
...

They always have at least two underscores before "imp". I can adjust the number of underscores AFTER "imp" using dlltool options like -U, --no-leading-underscore. I can also add an alias for every symbol with THREE underscores before "imp" using the -C option in dlltool. However, it doesn't seem that there's an option to remove one underscore before imp.

If I run the same `nm` command on the .a file I created for the other driver library (the one that DOES work) it also has two underscores before imp, every time, but the linker is fine with it in that case.

Any ideas/suggestions? Am I missing something here?

Chris

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

John Brown
1) Run nm on the object files that you are trying to link to the
import library and compare the names with those in the library.

2) Post the command line that you use to link to the library.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Chris-2
Thanks John.

Here's the output of nm on the object linking against that lib:

$ nm VectorDriver.o | grep ncd
         U __imp__ncdActivateChannel
         U __imp__ncdCloseDriver
         U __imp__ncdClosePort
         U __imp__ncdGetDriverConfig
         U __imp__ncdGetReceiveQueueLevel
         U __imp__ncdOpenDriver
         U __imp__ncdOpenPort
...

While the linker still gives errors like this:
undefined reference to `_imp__ncdGetDriverConfig'


The command used to link:
g++  -o dist/sidtest build/SIDTest_Windows/MinGW-Windows/source/candevice/windows/VectorDriver.o <...more of my .o files...> lib/windows/ia32/libvcinpl.a lib/windows/ia32/libvcand32.a -static -static-libgcc -static-libstdc++

Both libvcinpl.a and libvcand32a were generated by me, from reimp/dlltool (and as to add the obj file reimp left me) in the former case which works and gendef/dlltool in the latter which doesnt.

I did get the project linking and running fine yesterday (even when I call functions from that lib) by just linking against the dll instead for the second library (vcand32.dll). This doesn't work for the first library (vcimpl.dll). I got the idea from this page https://www.sourceware.org/binutils/docs-2.21/ld/WIN32.html in the section "direct linking to a dll"... 

So now my link command looks like this:
g++  -o dist/sidtest build/SIDTest_Windows/MinGW-Windows/source/candevice/windows/VectorDriver.o <...more of my .o files...> lib/windows/ia32/libvcinpl.a lib/windows/ia32/vcand32.dll -static -static-libgcc -static-libstdc++


I guess it's not clear to me though what `ln` is able to figure out about the DLL that I wasn't able to, or why this method works for one of my DLLs but not the other.

Chris

On Fri, Feb 19, 2016 at 3:46 AM, John Brown <[hidden email]> wrote:
1) Run nm on the object files that you are trying to link to the
import library and compare the names with those in the library.

2) Post the command line that you use to link to the library.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

John Brown

On  Friday, February 19, 2016 11:24 AM, Chris wrote:
> The command used to link:
>
> g++  -o dist/sidtest build/SIDTest_
> Windows/MinGW-Windows/source/candevice/windows/VectorDriver.o
> <...more of my .o files...>
> lib/windows/ia32/libvcinpl.a lib/windows/ia32/libvcand32.a
> -static -static-libgcc -static-libstdc++

Strange. The -static flag in your command line tells gcc not to link
against share libraries. From gcc --help -v:

-Bstatic, -dn, -non_shared, -static
                              Do not link against shared libraries

So gcc is correct to say that the functions cannot be found.

However, you say that your successful command that links directly
to the DLL instead of the import library also includes -static.

Anyway, try removing -static from the unsuccessful command line.

Also, I am just noticing that you call the import library libvcand32.a.
It should be called libvcand32.dll.a. The static library (if you had one)
would be called libvcand32.a. I don't know whether it matters or not,
but I would make that change also.

Regards,
John Brown.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Chris-2
I gave each suggestion a shot but to no avail.

I was under the impression the -static applied to libraries listed after it. I know that the two commands after that are supposed to link statically to those two libraries, but if I remember correctly I had a problem building my last project with those two flags unless I added -static before them. However, I took the -static flag away in my project and it links fine so I guess it wasn't needed. It didn't allow me to link against my libvcand32.a. I also renamed both libraries to .dll.a, but that didn't help in this case.

Chris

On Fri, Feb 19, 2016 at 7:26 PM, John Brown <[hidden email]> wrote:

On  Friday, February 19, 2016 11:24 AM, Chris wrote:
> The command used to link:
>
> g++  -o dist/sidtest build/SIDTest_
> Windows/MinGW-Windows/source/candevice/windows/VectorDriver.o
> <...more of my .o files...>
> lib/windows/ia32/libvcinpl.a lib/windows/ia32/libvcand32.a
> -static -static-libgcc -static-libstdc++

Strange. The -static flag in your command line tells gcc not to link
against share libraries. From gcc --help -v:

-Bstatic, -dn, -non_shared, -static
                              Do not link against shared libraries

So gcc is correct to say that the functions cannot be found.

However, you say that your successful command that links directly
to the DLL instead of the import library also includes -static.

Anyway, try removing -static from the unsuccessful command line.

Also, I am just noticing that you call the import library libvcand32.a.
It should be called libvcand32.dll.a. The static library (if you had one)
would be called libvcand32.a. I don't know whether it matters or not,
but I would make that change also.

Regards,
John Brown.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Eli Zaretskii
In reply to this post by John Brown
> From: John Brown <[hidden email]>
> Date: Sat, 20 Feb 2016 01:26:55 +0000
>
> Also, I am just noticing that you call the import library libvcand32.a.
> It should be called libvcand32.dll.a. The static library (if you had one)
> would be called libvcand32.a. I don't know whether it matters or not,

It doesn't matter (though I agree it's better to stick to .dll.a).
E.g., all the import libraries provided with MinGW w32api package are
*.a files, and GCC uses them with no problems.

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

John Brown
In reply to this post by Chris-2

On Friday, February 19, 2016 10:42 PM, Chris wrote
>
> >On Fri, Feb 19, 2016 at 7:26 PM, John Brown  <[hidden email]> wrote:
 
> > Anyway, try removing -static from the unsuccessful command line.

> I gave each suggestion a shot but to no avail.

Let us consider your gendef-generated DEF file:
LIBRARY "vcand32.dll"
EXPORTS
ncdOpenDriver
ncdGetDriverConfig@8
ncdOpenPort@24
...

Your import library exports stdcall names such as ncdDriverConfig@8.
Gendef thinks that the functions are stdcall functions. On the other
hand,  your .o file contains ncdDriverConfig (without the "@8"). The
compiler thinks that the functions follow the C calling convention. You
have to correct the mismatch.The first step is to establish whether the
functions are C functions or stdcall functions.

If they are C functions, then gendef is wrong and you
can fix your problem by removing the "@<total-bytes-in-parameter-list>"
suffix from the DEF file and rebuilding the import library. The question
would then become: why did gendef think that they were stdcall functions?

If they really are stdcall functions, then you need to check the header
file that declares these functions to see why stdcall was not included in
the declarations when your .c  files were compiled. Maybe command line
#defines are present when you build your project but not when you ran
gendef so that the functions end up getting declared differently because
of conditional compilation.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Keith Marshall
In reply to this post by Eli Zaretskii
On 20/02/16 08:40, Eli Zaretskii wrote:
>> From: John Brown <[hidden email]>
>> Date: Sat, 20 Feb 2016 01:26:55 +0000
>>
>> Also, I am just noticing that you call the import library libvcand32.a.
>> It should be called libvcand32.dll.a. The static library (if you had one)
>> would be called libvcand32.a. I don't know whether it matters or not,
>
> It doesn't matter ...

To be strictly accurate, we need to add a proviso: it doesn't matter,
provided there is no static linking alternative to use of the DLL; i.e.
when the application will link dynamically to foo.dll, and there is no
possibility that -lfoo might refer to a static libfoo.a, then an import
library for foo.dll may be called either libfoo.dll.a or libfoo.a, and
-lfoo will "just work", for dynamic linking.

The situation is entirely different, in the case where libbar.a is a
static library alternative to bar.dll; in this case, an import library
for bar.dll must be called libbar.dll.a; by default, -lbar will resolve
as libbar.dll.a, unless the linker's -Bstatic option is in effect, at
the time when -lbar is processed, so selecting the static libbar.a.

> (though I agree it's better to stick to .dll.a).

I agree too; it's unambiguous, and potentially less confusing for us humans.

> E.g., all the import libraries provided with MinGW w32api package are
> *.a files, and GCC uses them with no problems.

That is an historical artefact, from the days before the conventions for
handling of libfoo.a vs. libfoo.dll.a were well established.  There may
be an argument for renaming them, in a future release, but it has always
been dismissed as "hardly worth the effort".

--
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
[hidden email]

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:[hidden email]?subject=unsubscribe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Robert Miles
In reply to this post by Chris-2
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
unless you understand the internals of that library well enough to
understand the usually undocumented restrictions on calling it.

I've seen two underscores at the beginning of names related to the CUDA
method of running parts of the program on the GPU of your graphics
board instead of running it on the CPU.

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.  It's very difficult
to have part of a program run in 32-bit mode but another part in 64-bit
mode, and still have both parts work.  Drivers are normally required to
run in the same mode as the operating system.

Therefore, something to check for is whether you're trying to reach a
DLL compiled in a different mode from the mode the main program
was compiled in.

Robert

---

Date: Thu, 18 Feb 2016 15:35:15 -0600
From: Chris <[hidden email]>

I'm trying to link my mingw gcc project to two hardware driver libraries
presumably compiled with MSVC.

The first one worked fine following the guide on the mingw site... I used
reimp to create a .def file from the .lib, then dlltool to create the .a
file I imported into my project.

The second one is yet to work for me. If I run reimp on the .lib, it
produces no output (though it pulls in/creates a 1-byte .dll in the working
directory). If I run reimp -S on the lib, though, it does list all of the
symbols.

Next I tried using both gendef and pexports to create a def file from the
lib. Either way looks pretty much the same. Here's the output from gendef,
truncated:

;
; Definition file of vcand32.dll
; Automatic generated by gendef
; written by Kai Tietz 2008
;
LIBRARY "vcand32.dll"
EXPORTS
ncdOpenDriver
ncdGetDriverConfig@8
ncdOpenPort@24
ncdSetChannelMode@16
ncdSetChannelOutput@12
ncdSetChannelTransceiver@20
ncdSetChannelParams@20
ncdSetChannelParamsC200@16
ncdSetChannelBitrate@12
ncdSetChannelAcceptance@12
ncdSetTimerRate@8
...

Then I use dlltool to create a .a file from that and the original dll. The
problem is, no matter what options I use to create the .a file, the linker
gives an error like "undefined reference to `_imp__ncdOpenDriver'" for
every call. Notice there is one underscore before imp and two after. If I
run `nm libvcand32.a | grep imp` I get lines like this:

00000000 I __imp__ncdOpenPort
00000000 I __imp__ncdOpenDriver
00000000 I __imp__ncdGetState
00000000 I __imp__ncdGetReceiveQueueLevel
00000000 I __imp__ncdGetEventString
00000000 I __imp__ncdGetErrorString
...

They always have at least two underscores before "imp". I can adjust the
number of underscores AFTER "imp" using dlltool options like -U,
--no-leading-underscore. I can also add an alias for every symbol with
THREE underscores before "imp" using the -C option in dlltool. However, it
doesn't seem that there's an option to remove one underscore before imp.

If I run the same `nm` command on the .a file I created for the other
driver library (the one that DOES work) it also has two underscores before
imp, every time, but the linker is fine with it in that case.

Any ideas/suggestions? Am I missing something here?

Chris


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Keith Marshall
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
[hidden email]

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:[hidden email]?subject=unsubscribe

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Chris-2
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 <[hidden email]> 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
[hidden email]

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:[hidden email]?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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

John Brown
In reply to this post by Keith Marshall
Chris <chricro@...> writes:

>
> I found out a little bit more:
> ... 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  <at> XX after each symbol, while the
> Borland one does not. So:   
> ncdActivateChannel              @23 // Borland
> vs
> ncdActivateChannel@8            a@23  //MSVC
>  Running dlltool using  the borland .def file gave me a .dll.a
>cthat I can link against (although I'm not sure why running it on
> the MSVC one with the -k option wouldn't, then?).
>

If you the `add-stdcall-alias' flag to your dlltool command line, you
will create a DLL that exports 2 names for each function:
ncdActivateChannel@8 *and* ncdActivateChannel. This latter name
(from the Borland .def file) seems to be the name that the linker
is looking for. You will probably still experience the same problems
that you describe below.

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

As I said in my last email, I believe that that you have a mismatch
in calling conventions. That is, the compiler is generating code in
your .o files to call c functions, but the functions are actually
stdcall functions, or vice versa. This is how I would find out what
is happening.

1) Locate the declaration of ncdActivateChannel and determine the
calling convention (which is C by default). You might see something
like:
#if defined(_MSC_VER)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
#elif defined(__BORLANDC__)
/* Borland stdcall function declaration goes here. I don't
   remember how they do it
*/
...
#else
/* Unknown compiler - you tell me how to indicate __stdcall */
int ncdActivateChannel(type1 arg1, type2 arg2);
#endif

Note that it is possible that no #if matches __MINGW32__, in which
case the default declaration is the one that would be selected
when you compile with MinGW.

If it turns out that your functions are not marked as stdcall, you
will have to modify the header. If the _MSC_VER branch is OK, you
might get away with
#if defined (_MSC_VER) || defined (__MINGW32__)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
int __stdcall ncdBlahBlahBlah(...
...
wherever you see #if defined(_MSC_VER).

Another option may be to add the -mrtd switch (which changes the
default calling convention) to your gcc command line *instead of*
modifying the function declarations.

After you have fixed the header, build the import library using the
MSVC .def (with @n suffixes) and include --add-stdcall-alias in the
dlltool command line.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Chris-2
John,

Thanks for the prompt and detailed response.

I was able to set all of the calling conventions to __stdcall. Then I was able to link the .dll.a that I build with dlltool using the MSVC def file (with @XX in it). However, at runtime my program closes with a Windows pop-up dialog saying: "The procedure entry point ncdActivateChannel@8 could not be located in the dynamic link library vcand32.dll".

Why am I supposed --add-stdcall-alias in dlltool's options when the def already contains @XX for every symbol? Whether I include it or not, the result is the same:

00000000 I __imp__ncdActivateChannel@8
00000000 T _ncdActivateChannel@8

In fact, this is the case whether I use any of the following:
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a --kill-at
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a --add-stdcall-alias


At least in the --kill-at version I would have expected to see _ncdActivateChannel without @8.

While editing the header I noticed that every function also has __declspec(dllimport) before __stdcall as well, if that changes things.

Chris




On Wed, Feb 24, 2016 at 6:41 AM, John Brown <[hidden email]> wrote:
Chris <chricro@...> writes:

>
> I found out a little bit more:
> ... 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  <at> XX after each symbol, while the
> Borland one does not. So:   
> ncdActivateChannel              @23 // Borland
> vs
> ncdActivateChannel@8            a@23  //MSVC
>  Running dlltool using  the borland .def file gave me a .dll.a
>cthat I can link against (although I'm not sure why running it on
> the MSVC one with the -k option wouldn't, then?).
>

If you the `add-stdcall-alias' flag to your dlltool command line, you
will create a DLL that exports 2 names for each function:
ncdActivateChannel@8 *and* ncdActivateChannel. This latter name
(from the Borland .def file) seems to be the name that the linker
is looking for. You will probably still experience the same problems
that you describe below.

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

As I said in my last email, I believe that that you have a mismatch
in calling conventions. That is, the compiler is generating code in
your .o files to call c functions, but the functions are actually
stdcall functions, or vice versa. This is how I would find out what
is happening.

1) Locate the declaration of ncdActivateChannel and determine the
calling convention (which is C by default). You might see something
like:
#if defined(_MSC_VER)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
#elif defined(__BORLANDC__)
/* Borland stdcall function declaration goes here. I don't
   remember how they do it
*/
...
#else
/* Unknown compiler - you tell me how to indicate __stdcall */
int ncdActivateChannel(type1 arg1, type2 arg2);
#endif

Note that it is possible that no #if matches __MINGW32__, in which
case the default declaration is the one that would be selected
when you compile with MinGW.

If it turns out that your functions are not marked as stdcall, you
will have to modify the header. If the _MSC_VER branch is OK, you
might get away with
#if defined (_MSC_VER) || defined (__MINGW32__)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
int __stdcall ncdBlahBlahBlah(...
...
wherever you see #if defined(_MSC_VER).

Another option may be to add the -mrtd switch (which changes the
default calling convention) to your gcc command line *instead of*
modifying the function declarations.

After you have fixed the header, build the import library using the
MSVC .def (with @n suffixes) and include --add-stdcall-alias in the
dlltool command line.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Chris-2
By the way, when I said "The result is the same" I meant the result of `nm libvcand32.dll.a | grep ncdActivateChannel`.

On Wed, Feb 24, 2016 at 9:39 AM, Chris <[hidden email]> wrote:
John,

Thanks for the prompt and detailed response.

I was able to set all of the calling conventions to __stdcall. Then I was able to link the .dll.a that I build with dlltool using the MSVC def file (with @XX in it). However, at runtime my program closes with a Windows pop-up dialog saying: "The procedure entry point ncdActivateChannel@8 could not be located in the dynamic link library vcand32.dll".

Why am I supposed --add-stdcall-alias in dlltool's options when the def already contains @XX for every symbol? Whether I include it or not, the result is the same:

00000000 I __imp__ncdActivateChannel@8
00000000 T _ncdActivateChannel@8

In fact, this is the case whether I use any of the following:
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a --kill-at
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a --add-stdcall-alias


At least in the --kill-at version I would have expected to see _ncdActivateChannel without @8.

While editing the header I noticed that every function also has __declspec(dllimport) before __stdcall as well, if that changes things.

Chris




On Wed, Feb 24, 2016 at 6:41 AM, John Brown <[hidden email]> wrote:
Chris <chricro@...> writes:

>
> I found out a little bit more:
> ... 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  <at> XX after each symbol, while the
> Borland one does not. So:   
> ncdActivateChannel              @23 // Borland
> vs
> ncdActivateChannel@8            a@23  //MSVC
>  Running dlltool using  the borland .def file gave me a .dll.a
>cthat I can link against (although I'm not sure why running it on
> the MSVC one with the -k option wouldn't, then?).
>

If you the `add-stdcall-alias' flag to your dlltool command line, you
will create a DLL that exports 2 names for each function:
ncdActivateChannel@8 *and* ncdActivateChannel. This latter name
(from the Borland .def file) seems to be the name that the linker
is looking for. You will probably still experience the same problems
that you describe below.

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

As I said in my last email, I believe that that you have a mismatch
in calling conventions. That is, the compiler is generating code in
your .o files to call c functions, but the functions are actually
stdcall functions, or vice versa. This is how I would find out what
is happening.

1) Locate the declaration of ncdActivateChannel and determine the
calling convention (which is C by default). You might see something
like:
#if defined(_MSC_VER)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
#elif defined(__BORLANDC__)
/* Borland stdcall function declaration goes here. I don't
   remember how they do it
*/
...
#else
/* Unknown compiler - you tell me how to indicate __stdcall */
int ncdActivateChannel(type1 arg1, type2 arg2);
#endif

Note that it is possible that no #if matches __MINGW32__, in which
case the default declaration is the one that would be selected
when you compile with MinGW.

If it turns out that your functions are not marked as stdcall, you
will have to modify the header. If the _MSC_VER branch is OK, you
might get away with
#if defined (_MSC_VER) || defined (__MINGW32__)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
int __stdcall ncdBlahBlahBlah(...
...
wherever you see #if defined(_MSC_VER).

Another option may be to add the -mrtd switch (which changes the
default calling convention) to your gcc command line *instead of*
modifying the function declarations.

After you have fixed the header, build the import library using the
MSVC .def (with @n suffixes) and include --add-stdcall-alias in the
dlltool command line.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

Chris-2
I've been working more on trying to get this going. I tried adding non-annotated aliases to the def file myself both ways, so:
ncdActivateChannel          @23
...
ncdActivateChannel@8 = ncdActivateChannel
...


as well as
ncdActivateChannel@8        @23
...
ncdActivateChannel = ncdActivateChannel@8
...


and in both cases it links but has the same entry point error.


I also looked at the vcand32.dll file in MS's Dependency Walker and it shows all the exported functions without @XX annotations. Does this indicate that for the DLL expected calling convention is __cdecl instead of __stdcall or is it not conclusive?



The header checks for the macro __cplusplus and wraps everything in extern "C" {} if it's present (it is). Then:
#if (__FLAT__) || defined(_WIN32) || defined(__WIN32__) || defined(WIN32)
 #if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__)
  #define _EXPORT_API     __stdcall
 #else
  #define _EXPORT_API
 #endif
#else
 #define _EXPORT_API       _far _pascal
#endif

#ifndef DYNAMIC_CANDRIVER_DLL
 // not used for dynamic load of dll
 #define _EXPORT_DECL  __declspec(dllimport) _EXPORT_API
 #define _EXPORT_DEF  __declspec(dllimport) _EXPORT_API
#endif


Where _WIN32 was already defined, I define _STDCALL_SUPPORTED before including the header, and DYNAMIC_CANDRIVER_DLL is not defined.


On Wed, Feb 24, 2016 at 9:40 AM, Chris <[hidden email]> wrote:
By the way, when I said "The result is the same" I meant the result of `nm libvcand32.dll.a | grep ncdActivateChannel`.

On Wed, Feb 24, 2016 at 9:39 AM, Chris <[hidden email]> wrote:
John,

Thanks for the prompt and detailed response.

I was able to set all of the calling conventions to __stdcall. Then I was able to link the .dll.a that I build with dlltool using the MSVC def file (with @XX in it). However, at runtime my program closes with a Windows pop-up dialog saying: "The procedure entry point ncdActivateChannel@8 could not be located in the dynamic link library vcand32.dll".

Why am I supposed --add-stdcall-alias in dlltool's options when the def already contains @XX for every symbol? Whether I include it or not, the result is the same:

00000000 I __imp__ncdActivateChannel@8
00000000 T _ncdActivateChannel@8

In fact, this is the case whether I use any of the following:
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a --kill-at
$ dlltool --input-def vcandm32.def --dllname vcand32.dll --output-lib libvcand32.dll.a --add-stdcall-alias


At least in the --kill-at version I would have expected to see _ncdActivateChannel without @8.

While editing the header I noticed that every function also has __declspec(dllimport) before __stdcall as well, if that changes things.

Chris




On Wed, Feb 24, 2016 at 6:41 AM, John Brown <[hidden email]> wrote:
Chris <chricro@...> writes:

>
> I found out a little bit more:
> ... 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  <at> XX after each symbol, while the
> Borland one does not. So:   
> ncdActivateChannel              @23 // Borland
> vs
> ncdActivateChannel@8            a@23  //MSVC
>  Running dlltool using  the borland .def file gave me a .dll.a
>cthat I can link against (although I'm not sure why running it on
> the MSVC one with the -k option wouldn't, then?).
>

If you the `add-stdcall-alias' flag to your dlltool command line, you
will create a DLL that exports 2 names for each function:
ncdActivateChannel@8 *and* ncdActivateChannel. This latter name
(from the Borland .def file) seems to be the name that the linker
is looking for. You will probably still experience the same problems
that you describe below.

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

As I said in my last email, I believe that that you have a mismatch
in calling conventions. That is, the compiler is generating code in
your .o files to call c functions, but the functions are actually
stdcall functions, or vice versa. This is how I would find out what
is happening.

1) Locate the declaration of ncdActivateChannel and determine the
calling convention (which is C by default). You might see something
like:
#if defined(_MSC_VER)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
#elif defined(__BORLANDC__)
/* Borland stdcall function declaration goes here. I don't
   remember how they do it
*/
...
#else
/* Unknown compiler - you tell me how to indicate __stdcall */
int ncdActivateChannel(type1 arg1, type2 arg2);
#endif

Note that it is possible that no #if matches __MINGW32__, in which
case the default declaration is the one that would be selected
when you compile with MinGW.

If it turns out that your functions are not marked as stdcall, you
will have to modify the header. If the _MSC_VER branch is OK, you
might get away with
#if defined (_MSC_VER) || defined (__MINGW32__)
int __stdcall ncdActivateChannel(type1 arg1, type2 arg2);
int __stdcall ncdBlahBlahBlah(...
...
wherever you see #if defined(_MSC_VER).

Another option may be to add the -mrtd switch (which changes the
default calling convention) to your gcc command line *instead of*
modifying the function declarations.

After you have fixed the header, build the import library using the
MSVC .def (with @n suffixes) and include --add-stdcall-alias in the
dlltool command line.

Regards,
John Brown.
------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

John Brown
In reply to this post by Chris-2
Chris <chricro@...> writes:


>
> John,
> Thanks for the prompt and detailed response.
> I was able to set all of the calling conventions to __stdcall. Then
> I was able to link the .dll.a that I build with dlltool using the
> MSVC def file (with  <at> XX in it)
> ...
> Why am I supposed --add-stdcall-alias in dlltool's options when the def
already contains  <at> XX for every symbol?

Because the alias is the name *without* @n. When you --add-stdcall-alias,
you export the additional name ncdActivateChannel so the the library
exports two names for the same function, unless you add the --kill-at
option, which suppresses the @n names.

 Whether I include it or not, the result is the same:
>
>
>
> 00000000 I __imp__ncdActivateChannel <at> 800000000 T _ncdActivateChannel
<at> 8
>
>
> While editing the header I noticed that every function also has
__declspec(dllimport) before __stdcall as well, if that changes things.
>

This is fine. That is what your function prototypes should look like
if you intend to link to an import library, although I think the
linker is smart enough to find the function whether the __declspec\
is there or not.
 
Regards,
John Brown.


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems creating linkable file from MSVC .lib

John Brown
In reply to this post by Chris-2
Chris <chricro@...> writes:

>
> I've been working more on trying to get this going. I tried adding
> non-annotated aliases to the def file myself both ways,
>  ...
> and in both cases it links but has the same entry point error.
> I also looked at the vcand32.dll file in MS's Dependency Walker and it
> shows all the exported functions without  <at> XX annotations. Does this
> indicate that for the DLL expected calling convention is __cdecl instead
> of __stdcall or is it not conclusive?

It is not conclusive, as previously described mechanisms exist for
choosing whether the names are decorated or not. For example, if you
look at a Windows DLL such as kernel32.dll in Dependency Walker, you
will not see decorated names, but kernel32.dll exports __stdcall
functions. By the way, are you able to call functions that do not
take any arguments without the runtime errors? I believe that that
would indicate that it is a calling convention mismatch.

Another quick test would be trying to call the functions from
Visual Basic (not .NET; create a macro in Ms Word or Excel). VB
can call stdcall functions in a DLL, but cdecl functions will cause
a run time error:
Run-time Error '49':
Bad DLL Calling Convention

Regards,
John Brown.


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe