I have a little application running on Linux and want to port it to Windows. I found that with Cygwin i will be able to do it simple by linking the application with the cygwin1.dll library which make available a lot of the POSIX and other standard functions. I read the FAQ and the User Guide on the site of Cygwin but didn't find or didn't understand how can I link my source with this library.
My application uses GTK+ and I successfully compiled and link it on Windows with MinGW but I have to disable some of the functionality .Now that I find Cygwin I would like to link with it to make available again this functionality.
Generally you compile your source inside of Cygwin to produce the Windows binary. I'm pretty sure Cygwin will take care of linking to the proper dlls for you.
When you finally get the binary compiled, make sure that the cygwin1.dll is in the PATH specified by Windows.
Related
I'm working on a project, which targets both Windows and Linux (and possible in the future MacOS). It consists of some applications with several shared libraries. It is written in modern C++ and modern CMake. It also uses 3rd-party libraries like Qt, OpenCV, Boost, GraphicsMagick, samplerate, sndfile. Those dependencies are handled through Conan package manager. I'm building both on Linux (Ubuntu 18.04, GCC 8.1) and Windows (via WSL - also Ubuntu 18.04, MinGW-w64 8.1). I'm using fairly recent versions of 3rd-party libraries with custom built options (strictly speaking - different versions than available on Ubuntu's APT, e.g. Qt v5.11.3, or custom built of GraphicsMagick)
I'm using CPack. On Windows I'm building NSIS installer, but on Linux I would like to use DEB generator (may be other if needed). All of my targets (written apps and shared libs) have appropriate CMake's INSTALL configurations, so they are copied correctly into the generated installers (component based installation). The real problem comes with packaging of 3rd-party dependencies.
Problem
Strictly speaking, I have no idea, how to do it well using CMake+CPack+Conan, both on Linux and Windows. I've read a lot of articles and posts, but I'm stucked. I would like to have something, that automatically bundles into the installer all 3rd party libraries used by project with needed plugins and, what is the most important, with needed system/compiler libraries (libgomp, libstdc++ and so on).
Possible solution
To my surprise, on Windows, this task is fairly easy, because every DLL used by app (my libs, 3rd-party libs and system/compiler libs) needs to be located where executable is. I'm engaging Conan into this, by importing all used DLLs into bin directory. In the end, in most naive way of packaging, I will just copy the bin directory into the installer and it should work. But I'm not sure, if this approach is OK.
On Linux, things are more complicated. First, there is arleady a package manager. Unfortunately, libraries/compilers available there are too old for me (e.g. on APT there is only Qt 5.9.6 ) and are built using different compile options. So, the only way for me is to ship them with my software (like in Windows). There are also issues with searching for dynamic libraries by ld, RPATH handling and so on. At the moment, the only solution I see is to write something like 'launcher' for my app, which sets LD_LIBRARY_PATH before program starts. After that, in this case we can just copy bin or lib directory to the DEB installer and this should work. But still, I don't know if this is correct approach.
Other solutions
I've also looked into other solutions. One of them was BundleUtilities from CMake. It doesn't work for me. It has a lot of problems in recognizing, whether some library is system or local one. Especially in WSL, where it stucked in processing dependencies to USER32.dll, KERNEL32.dll. BundleUtilities in Windows worked for me only with MSYS, but in MSYS I've failed to compile some 3rd-party libraries (GraphicsMagicks via Conan) and that's the reason, why I'm using WSL.
Summary
I'm looking for good and verified method of packaging C++ projects with multiple apps, libs and shipped 3rd-party libs, both for Windows and Linux. How are you doing things like this? Are you just copying bin and/or lib dirs to the installers? How (in terms of CMake/CPack code) are you doing that? INSTALL(DIRECTORY ...), or similar? I'm not sure, but I think that this problem should be already solved in the industry. ;)
Thanks for all suggestions.
First, Conan is a package manager for development, not for distribution, that's why you didn't find an easy way to solve your problem. Second, most of discussions are made at Conan issue, including bugs and questions. There you will find a big community + Conan devs which are very helpful.
with needed system/compiler libraries
This is not part of Conan. Why you don't use static linkage for system libraries?
Talking about CPack, we have an open discussion about it usage with Conan: https://github.com/conan-io/conan/issues/5655
Please, join us.
I see few options for your case:
on package method, run self.copy and all dependencies from self.cpp_deps, which includes all libraries, so you can run Cpack
Use Conan deploy generator to deploy all artifacts, and using a hook you can run cpack or any other installer tool
Out friend SSE4 is writing a new blog post about Deployment + Conan, I think it can help you a lot. You can read a preview here.
Regards!
We have Matlab R2017a installed on a RHEL 7.3 machine and I can provide verbose installation instructions if necessary. We have the Matlab library paths saved in /etc/ld.so.conf.d/matlab.conf and have run ldconfig to make sure the paths get picked up. Matlab works and everything is functional. However, Matlab seems to come bundled with it's own versions of libraries such as libstdc++, libicui18n, and others.
I'm trying to build and link a non-Matlab executable with the two libraries mentioned above and it's linking against Matlab's and not the system. How can I tell the linker to use the system provided libraries? I'm pretty sure this isn't a Matlab-specific problem, but that happens to be the environment I'm working in. Any thoughts would be greatly appreciated.
Here is what our /etc/ld.so.conf.d/matlab.conf file looks like. Based on some testing, it does look like all three of these are necessary.
/opt/MATLAB/R2017a/bin/glnxa64
/opt/MATLAB/R2017a/runtime/glnxa64
/opt/MATLAB/2017a/sys/os/glnxa64
There are libraries installed in the runtime that depend on libraries installed in sys/os. The libraries in sys/os are the ones conflicting with the RHEL system libraries (such as libstdc++).
I have been reading up on cross platform development with OpenGL for games. We are looking at developing a game which will be available to Linux users too. I have however come across something I am not quite getting my head around.
How to create a portable linux executable? Specifically how to get the various different versions of OpenGL / Mesa3D to work in one (or more) executable file/s (we do not want to distribute the source).
Over on Linux Questions http://www.linuxquestions.org/questions/linux-software-2/hardware-acceleration-using-opengl-and-x11-876634/ someone goes in to detail on how Mesa3D / OpenGL work but what I am struggling to see is how I would go about using each distro's version of Mesa3D within my compiled executable (not even sure if it is possible).
From what I can tell I am required to dynamically link parts of the application together on each users machine, possibly through the use of an installer? If this is the case can we part compile the program and link at runtime for Mesa3D / OpenGL much like OpenGL's dll's can do on Windows?
Just link your executable dynamically against libGL.so and be done with it. The binary interface of that is common among all implementations of OpenGL.
From what I can tell I am required to dynamically link parts of the application together on each users machine, possibly through the use of an installer?
Not you do the linking and neither does a installer. The dynamic linking happens automatically when the executable is loaded. Dynamic linking is how DLLs get loaded in Windows and the *nix counterpart Shared Objects (.so) on *nix.
When building your program, you add the option -lGL to the linker command line and it will add a dynamic linkage entry to libGL.so to the exeutable. That you can then redistribute. When the program gets started on the target system, the dynamic linker will locate the libGL.so and load it.
This question already has answers here:
Using Windows DLL from Linux
(7 answers)
Closed 2 years ago.
Question: Is it possible to compile a program on linux using a .dll file?
Where this is going:
This .dll will be used to write a php extension to some proprietary software from a third party.
Background and Research:
I have been given a library called proprietary.lib. I was curious, as I have never seen the .lib extension before, so I typed:
file proprietary.lib
The output was:
proprietary.lib: current ar archive
I did some research and found that ar is more-or-less tar (and in fact, I guess tar has since replaced ar in most *nix environments).
Upon inspecting the ar manpage, I saw the t option, which displays a table listing of the contents of that archive. Cool. So I type:
ar t proprietary.lib
And get:
proprietary.dll
proprietary.dll
... (snip X lines) ...
Recent development may have changed the situation: There is a loadlibrary function for Linux available, that makes it possible to load a Windows DLL and then call functions within.
So, if the .dll file you have actually is a Windows DLL, you may find a way to use it in you software.
You could try extracting the ar file (Debian packages are ar files, fwiw) and run file on the contents.
You're not going to be able to use Windows DLLs without translation. The only DLL files that I know of that work natively on Linux are compiled with Mono.
If someone gave you a proprietary binary library to code against, you should verify it's compiled for the target architecture (nothing like trying to use am ARM binary on an x86 system) and that it's compiled for Linux.
That being said...good luck. I hate programming against third-party libraries where I have the documentation and the source.
.dll files are usually Windows shared libraries. (It's also possible that somebody on Linux has built a regular Linux library and called it .dll for some reason.)
It's possible you could link against them using Wine. Support for this was once in there as experimental - I don't know its current status.
Yes We can use dll with the help of wine .
just install wine64 in linux
sudo apt-get install wine64
Normal DLL files are Windows' linked libraries, so they cannot run on Linux directly, however it's possible to compile DLL files specifically for Linux using .NET Core.
Is there anyway to write dlls in linux?
Do I have to install windows to write dlls in linux? Right now one of my courses requires me to write a dll for this.
You should take a look into 'shared libraries'
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
Lots of folks are getting near the right answer but not providing it: gcc can generate win32 PE/COFF files without problem, and of course can always build as a cross compiler on any platform it can target. The binutils port targets windows .exe and .dll files natively, and there's a "dlltool" utility for handling the edge cases where Unix and Windows linkage metaphors are different.
Additionally, the "mingw32" project provides a set of link libraries and header files for building C applications against the win32 API. These likewise install just fine on any Unix.
Here's a site I turned up after a quick google with instructions for building the toolchain.
Not really. Building any kind of executable intended for OS "A" while using OS "B" is a process commonly known as cross-compilation. In this partciluar case, you would need a cross-compiler running on Linux, but targetting Windows. I don't know any vendor selling such a product.