I'd like to build a Fortran program that will use a library with a specific interface, but I don't have the library currently installed on my system. I only need to compile the Fortran program, not run it. I assume that the system where my program is run will have the library installed in a standard location (i.e. /usr/lib).
Is this possible?
Specifically, I'd like to use the Conda-build system to compile a program that links to the MATLAB library (libmex). Since MATLAB is not installable with Conda or other package managers, I was hoping I could somehow build my program in such a way that it has the correct function call to libmex but requiring that users will have libmex installed in a place where my program can find it.
Related
I use Cygwin to build source code to DLL used by windows app.
When I use GCC core / GCC g++, the app crash if it calls function (which includes printf or malloc) in DLL.
When I use Mingw64-x86_64-gcc-core / Mingw64-x86_64-gcc-g++ it reports error like sys/socket.h：No such file or directory.
Can anyone explain how to do it? Thanks.
The first problem is due to the tentative to build a stand alone DLL (not depending on cygwin1.dll) using cygwin only specific tools.
You have collision between multiple malloc and other C library call present in cygwin1.dll.
The second is due to the fact that sys/socket.h does not exist on Windows
see for possible solution:
Using sys/socket.h functions on windows
So you need to define what is your target : Cygwin/Posix or Windows and choose programming style and tools accordingly, you can not mix.
I'm attempting to build TensorFlow's C++ library for Windows XP. While I've been able to build and use it on Windows 10, 32-bit XP isn't working. The background: I'm working on a COM module that calls fuctions from tensorflow.dll. My build environment:
Visual Studio 2017 15.7
CMake 3.11.1
TensorFlow 1.8
Windows 10
The sequence I use to build tensorflow.dll is:
Open "x64_x86 Cross Tools Command Prompt for VS 2017"
Try to force the use of functions availablbe in Win XP: set CXXFLAGS=/D_WINVER=0x0501 /D_WIN32_WINNT=0x0501
Add Git to path: set PATH=%PATH%;C:\Program Files (x86)\Git\bin
Fix CMake file for converting *.proto files to *.pb.h files as described here.
Configure CMake: cmake .. -A Win32 -T v141_xp,host=x64 -DCMAKE_SYSTEM_VERSION=7.0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=C:\Users\williams\AppData\Local\Continuum\Anaconda3\envs\tensorflow\python.exe -Dtensorflow_BUILD_SHARED_LIB=ON -Dtensorflow_BUILD_PYTHON_BINDINGS=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS="/arch:IA32"
Build: cmake --build . --target tensorflow --config Release -- /fileLogger /m:1 /p:CL_MPCount=1
The last step also involves some manual labour as the build process doesn't copy .lib files from the 3rd part dependencies to where they are needed. For whatever reason, a bunch of INSTALL projects never get run so I had to do that manually each time the build would fail while looking for a missing lib file. Once that was done, the build completed successfully.
Next I copy my COM module (a DLL) and the TensorFlow DLL over to a Windows XP virtual machine for testing and try to register the COM module, but get an error LoadLibrary("MyDLL.dll") - The specified procedure could not be found. I don't know what procedure it is looking for, so the best I can offer is that Dependency Walker highlights WS2_32.DLL and tells me it can't find inet_ntop and inet_pton.
Any suggestions on how to build TensorFlow so that it doesn't use these two functions?
P.S. suggestions of "Stop using XP, its old and no longer supported" don't help here. Upgrading to Windows 10 is an absolute last resort because of the disruption it would cause at the facility where this software will be tested.
Edit 1:
These two functions inet_pton and inet_ntop were only used in one file that forms part of Google Cloud Storage support in TensorFlow. The build process generated a tensorflow_static.lib in addition to tensorflow.dll. Linking against the static version and adding a few dependencies that aren't included in tensorflow_static.lib got rid of the code using inet_* functions.
My COM module still isn't working on Windows XP though because the file tensorflow\core\platform\windows\env.cc uses functions like CloseThreadpoolWork, submit SubmitThreadpoolWork, etc. that were only introduced in Windows Vista. It looks like I'll have to replace them with something else, as I don't see an alternative implementation in TensorFlow.
Additionally, I found that tensorflow\contrib\cmake\CMakeLists.txt forces _WIN32_WINNT=0x0A00 and that CXXFLAGS is the wrong environment variable to use. Changing it to CMAKE_CXX_FLAGS at least gets my macro definitions included, FWIW.
It is almost impossible to port tensorflow to windows xp, because:
TF's platform depedent code requires some Windows APIs later than winxp such as Thread Pool API. This would possibly bypassed by using third party thread pool libs.
The nsync, protobuf and eigen, which are core parts of TF, use C++11 thread_local, which makes them unable to run-time load as dll, see https://learn.microsoft.com/en-us/cpp/parallel/thread-local-storage-tls?view=vs-2017 for details. This later feature can theoretically be replaced by old windows TLS API, which requires many modifications on TF's core framework.
Anyway, if you really need the xp support, good luck with that.
In the end I gave up on this as simply being impossible. Even replacing the thread pool functions with something from Boost didn't help. If someone else manages to get this working, I'll gladly accept that as the answer, but so far this looks impossible.
It's said that library authors should ship their library with a config-file instead of a plain find-module.
Basically config-file are to be installed with the associated library on the system and can be used transparently by the user, whereas find-module is written by the user by his own when he finds out that the library hasn't any config-file.
But, what if I'm sure that my library will never be installed?
I'm doing embedded system development and it doesn't make much sense to install my static libraries on the system.
Different modules are organized as static libraries and handled by each project with git submodules.
Is there any way I can use config-files even in this scenario? Or, as library author, I should write a example of vanilla Find-module and say to client code "Take and copy this to your CMAKE_MODULE_PATH"?
Or maybe just tell the client code cmake to call add_subdirectory?
I'm trying to load a dll into my lua script and call the function. When I create the dll using GCC (under cygwin) and lua (5.2.4) I'm able to load the library & execute it without a problem.
However, when I create run the same script from SciTE, using Lua 5.1, the dll loads successfully. However, it does not execute. In the dll I'm trying to simply write two integers into a file.
t = package.loadlib("mylibrary.dll","myfunc")
t(23,45)
There are two questions here:
1. What format should the 'mylibrary.dll' be, for lua to understand and execute without problems - ELF or COFF.
2. Can I run dll (built under windows, obviously) under lua running on linux?
The question in your title seems to be very different from the cause of the problem you describe.
On the one hand, the format for dynamic libraries loaded by Lua is the format for the platform that the Lua code is running on. Just as you can't take a compiled Win32 executable and expect it to run on Linux, you can't take a compiled Win32 dll and expect it to load it on Linux. Obviously emulation tools like Wine exist, but those work by emulating Windows. You could run them within the emulator, but not outside of it.
But on the other hand, that is not the source of your problem. Your problem is that you're using a dynamic library that was built for one version of Lua with an application that was built for another version of Lua. That doesn't work; Lua does not retain compatibility between "minor" versions, only between revisions (Lua 5.1.3 vs. 5.1.4).
ELF or COFF, that isn't going to work.
I'm trying to write a cross-platform program in c++ that will load certain modules (shared libraries) at runtime. To do this I'm using the ClassLoader from Poco C++ Libraries. I've written a compiling chain using autoconf, automake and libtool. This shouldn't be any problem in a Linux environment, but the problem occurs in Windows. I'm using MinGW and MSYS when compiling to be able to make use of my Makefiles. ClassLoader uses the Windows-specific LoadLibrary() function to load the modules, which means I have to compile them as DLLs.
The class that I compile to a library inherits another class within the main application. Then when I try to run make, it complains a lot about undefined reference and refuses to build a shared library. I guess this is because of the name mangling. Or is it because I can't inherit a class outside of the library? (That class is not included in the sources for the library, but the header file is found)
I'm not really sure how much trouble it's going to bring that I insist on compiling under MinGW + MSYS but still make use of LoadLibrary(). Anyone with experience of this?
Under Windows, a DLL must have all of it's symbols resolved when it's built. Under Unixes, you can leave things unresolved until load-time, and this behavior is currently incorprated into your design.
To change that, you will probably have to break out the base class in the main application (and everything else that the DLL depends on) into it's own DLL. That way, when you link your library that subclasses, it can link to the new DLL and fully resolve it's symbols.
The catch is, you have to be able to build this new DLL with all of it's symbols resolved.