Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

static link ljackuw using gcc (mingw)


  • Please log in to reply
12 replies to this topic

#1 mijoac

mijoac
  • Members
  • 9 posts

Posted 28 May 2013 - 12:03 AM

Hi.

According to an other topic in this forum it is possible to static link this library. ( https://forums.labja...hp?showtopic=51 )

Unfortunately I can not static link the library using gcc (in mingw, Windows7).

What I tried: (note that the Labjack U12 driver has been installed to "D:\Programme\Labjack\", "lackuw.lib" is placed at "D:\Programme\Labjack\drivers")

mingw32-g++.exe -LD:\Programme\Labjack\drivers [...] -static -s -Bstatic -lljackuw [...]

Compiling works, and other libraries includes (such as pthread) are linked static, I do not need to offer them to the user.
The created executable is still depending on "ljackuw.dll".

The user of my application has no rights (windows 7) to install labjacku12 software and I would like to offer the application without any additional dll files.

Is there a way to make static linking work as I wish, or do I always need to offer the dll files for 32- and 64-bit Windows, together with my application?

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 28 May 2013 - 03:08 PM

Hi.

According to an other topic in this forum it is possible to static link this library. ( https://forums.labja...hp?showtopic=51 )

Unfortunately I can not static link the library using gcc (in mingw, Windows7).

What I tried: (note that the Labjack U12 driver has been installed to "D:\Programme\Labjack\", "lackuw.lib" is placed at "D:\Programme\Labjack\drivers")

mingw32-g++.exe -LD:\Programme\Labjack\drivers [...] -static -s -Bstatic -lljackuw [...]

Compiling works, and other libraries includes (such as pthread) are linked static, I do not need to offer them to the user.
The created executable is still depending on "ljackuw.dll".

The user of my application has no rights (windows 7) to install labjacku12 software and I would like to offer the application without any additional dll files.

Is there a way to make static linking work as I wish, or do I always need to offer the dll files for 32- and 64-bit Windows, together with my application?


Normally we just supply a .dll with a .lib file that has code to dynamically link to that .dll. However, I just built a .lib that can be used to statically link the .dll and uploaded it to here: http://files.labjack...ackuwstatic.zip (it's the 32-bit version).

I think linking to that .lib (built in Visual Studio) should accomplish what you are trying.

#3 mijoac

mijoac
  • Members
  • 9 posts

Posted 29 May 2013 - 12:34 AM

Hi. Thank you very much for the help. Unfortunately, linking to this lib produces a "undefined reference to '_imp__strcpy_s'". Neither linking to libmsvcr*, nor linking to glibc could solve this (especially as mingw does not support adding a "-lc" on windows). Do you have any ideas, how I could solve this? "_imp__strcpy_s" is not defined in any lib of microsoft visual c either.. EDIT: I used MS Visual C++ 6.0. When I changed to MS Visual C++ 2012, I realized, that strcpy_s is defined in libmsvcrt and in libcmt as mentioned below.

#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 03 June 2013 - 04:10 PM

Hi.

Thank you very much for the help.

Unfortunately, linking to this lib produces a "undefined reference to '_imp__strcpy_s'".
Neither linking to libmsvcr*, nor linking to glibc could solve this (especially as mingw does not support adding a "-lc" on windows).

Do you have any ideas, how I could solve this?

"_imp__strcpy_s" is not defined in any lib of microsoft visual c either..


I believe the strcpy functions are all in the Visual Studio CRT libraries. You could try linking to libcmt.lib, which I think is the static version.

I also changed some settings around and reuploaded to http://files.labjack...ackuwstatic.zip to try and get those things statically linked inside the .lib. The file size isn't much different but this version may work.

#5 mijoac

mijoac
  • Members
  • 9 posts

Posted 04 June 2013 - 03:37 AM

When I link to libcmt.lib, the compiler (G++ in MinGW) won't succeed, because of multiple definitions of some symbols (MinGW seems to force "-lmsvcrt"). I succeeded by linking strcpy_s to strcpy manually (renaming some other symbols, too), creating my own lib (attached c file) compiled as static link library with mingw. When I now link against the static ljackuw and against my renaming lib, I'm, compiling successfully and the created program also works with labjack u12 on a usb-port on a system without labjack software installed. Thank you very much for your help! For me, everything is fine now.

Attached Files

  • Attached File  main.c   311bytes   309 downloads


#6 mijoac

mijoac
  • Members
  • 9 posts

Posted 11 June 2013 - 08:14 AM

Hi. Unfortunately, I found an error using the static library. As long, as I only use DIOs, everything is fine, but using AIs fails: the "read" voltage is always -10V (in differential mode -20V). This problem occurs on both: a Windows XP (32-Bit) and a Windows 7 (64-Bit). When I change to the dynamic library (only tested on Windows 7 (64-Bit), yet, everything is fine with AINs, too. EDIT: I also tried to switch to dynamic library on a Windows XP (32-Bit) based machine, also "works around" this problem.

#7 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 11 June 2013 - 02:47 PM

Hi.

Unfortunately, I found an error using the static library.

As long, as I only use DIOs, everything is fine, but using AIs fails: the "read" voltage is always -10V (in differential mode -20V).

This problem occurs on both: a Windows XP (32-Bit) and a Windows 7 (64-Bit).

When I change to the dynamic library (only tested on Windows 7 (64-Bit), yet, everything is fine with AINs, too.


The static library is calling the same code as the dynamic one, so there shouldn't be much difference there. The only difference is how that code is called, so I would check the parameters being passed and see if you can verify that they are correct. For instance maybe it is reading a different channel than you are passing because of some weird issue. That specifically is easy to test for by grounding other channels and seeing if one of them happens to give the right voltage.

#8 mijoac

mijoac
  • Members
  • 9 posts

Posted 12 June 2013 - 12:18 AM

Hi. I checked all the parameters and all the settings, and they are exactly the same for the test with the dynamic and the static library. But, as you mentioned, there shouldn't be any difference in what the library calls. Therefore, I suspect my "linking library" to not work as expected, as the float value read by the function EAnalogIn, is always -20.f. Maybe linking _ftol2_sse to a simple cast is not correct, or the call of __security_check_cookie has a special meaning in your library. If I find a solution for this problem, I will write again.

#9 mijoac

mijoac
  • Members
  • 9 posts

Posted 12 June 2013 - 03:00 AM

I found an error in my linking of the strcpy_s function (attached current version). Corrected rename-library also leads to the error with the static library. Even tried to create functions that always return 0 for calls of strcpy_s and _ftol2_sse, still call of EAnalogIn(...) -> -10.f (and -20.f for differential channels). Tried this on all channels, even with channels connected to mass. Parameters are correct (checked in debugger) and verified to be the same when linking to the static and the dynamic library. Calls of EDigitalIn(...) work great with both libraries. Maybe the combination of a static linked libcrt and the usage of a gcc compiler in mingw (which forces to link to libmsvcrt under windows) leads to strange calls of functions like memcpy or sprintf or some other basic c/c++ functions.

Attached Files



#10 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 12 June 2013 - 03:30 PM

I found an error in my linking of the strcpy_s function (attached current version).

Corrected rename-library also leads to the error with the static library.
Even tried to create functions that always return 0 for calls of strcpy_s and _ftol2_sse, still call of EAnalogIn(...) -> -10.f (and -20.f for differential channels).

Tried this on all channels, even with channels connected to mass. Parameters are correct (checked in debugger) and verified to be the same when linking to the static and the dynamic library.

Calls of EDigitalIn(...) work great with both libraries.

Maybe the combination of a static linked libcrt and the usage of a gcc compiler in mingw (which forces to link to libmsvcrt under windows) leads to strange calls of functions like memcpy or sprintf or some other basic c/c++ functions.


The strcpy_s function is only called in GetErrorString() I believe, so that being the issue would be strange. What values do you get if you set demo mode variable in the EAnalogIn function?

The -10.0f and -20.0f imply that the driver is geting all zeros back from the U12 and then applying the calibration values. The "normal" cause of this is a broken ADC, but that wouldn't explain it in this case. Do you get any errors?

Does the GetFirmwareVersion() function work? Do you get correct values with the LJLogger application? Does LJTest give any errors?

#11 mijoac

mijoac
  • Members
  • 9 posts

Posted 13 June 2013 - 06:25 AM

The return value of EAnalogIn(...) and the value of the associated overvoltage value are always 0, in all: demo_mode with dynamic lib, usual mode with dynamic lib, demo_mode with static lib and usual mode with static lib. Result of GetFirmwareVersion() is 1 with both: dynamic and static library. LJLogger gives correct values, so my application does when using dynamic linking. LJTest prints following erors (when lines are connected to the devices): AI NC SF Test: Failed: Channel 1, -292,1 bits AI NC Diff1 Test: Failed: Channel 0, 52,0 bits AI NC Diff20 Test: Failed: Channel 0, 1046,8 bits EDIT: I casted the firmware version to long, the real result of GetFirmwareVersion() is 1.1f for me.

#12 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 17 June 2013 - 04:06 PM

Would it be possible to send us your program (both a dynamic and static linked version)? If we had that to test we could run it on a U12 here with our extra debugging tools and maybe get some idea of where the data is getting set wrong. You can send them to [email protected] or post them here.

#13 mijoac

mijoac
  • Members
  • 9 posts

Posted 17 June 2013 - 11:38 PM

Hi. I will try to create a minimum example, to send it to you. The current version of this program needs to many external libraries (e.g. PoDoFo for PDF creation, FLTK for gui, ...). As soon as I finished one, I will post it here.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users