I want to create a standalone executable from a C file so that the libraries that I'm using don't have to be installed on the computer that I'm running the executable on.
I'm using the libssh and libconfig libraries, both of which may need to be installed on the machine I'm running the executable on.
When I run my binary on a machine that doesn't have these libraries installed, I get:
error while loading shared libraries: libssh.so.4: cannot open shared object file: No such file or directory
Is there a way I can compile my program.c file so that it has the libssh binaries included within it?
See this Link http://api.libssh.org/master/libssh_linking.html about how to link the static version of the libssh. There must be similar instructions for libconfig.
Related
I am using gcc 8.1.0 on Windows. To install it I set up Code::Blocks on my computer and updated the environment variable list by adding the path to the gcc.exe program within the installation folder of CodeBlocks. The file editor I used was the built-in editor in Visual Studio. The terminal to compile was the power shell from Visual Studio as well.
In the library development folder I have the files mul.c and mul.h. Their content is irrelevant.
To compile the library I use the command:
gcc -c mul.c
When I run it, it creates a file object mul.o and not mul.lib. I needed to use the option -o mul.lib to successfully create the desired extension file. After placing the header, the .lib file and the main.c in the same parent folder I am obvioudly able to build the executable by running.
gcc main.c -I./include -L/static -lmul -o my_program.exe
I have two questions:
Why does gcc produces a .o if I am in a Windows environment?
I followed a tutorial that compile the static library under Linux and it names it libmul.o, in this way the -lmul option is able to retrieve the library. But if I call my generated static library libul.lib it generates the error:
C:/Program Files/CodeBlocks/MinGW/bin/../lib/gcc/x86_64-w64-ingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmul
collect2.exe: error: ld returned 1 exit status
Are these a normal behaviours by gcc, or is it side effect of making gcc available just by updating the Windows environmental variables list?
Thank you to the community in advance.
GCC comes from the *nix world where libraries have the .a extension. When using GCC+MinGW this remains the case.
Shared libraries in MinGW are .dll files but their libraries for linking are .dll.a files.
The advantage of .a files is that a lot of sources build out of the box on Windows with MinGW, especially when using MSYS2 shell.
If you use -l it will look for .a (or .dll.a for shared build) file adding the lib prefix and the extension automatically.
So -lmul will look for libmul.a (static, e.g. when --static linker flag is given) or libmul.dll.a (shared).
By the way, you are using quite an old GCC 8.1.0.
As I write this current version is 12.2.0. Check https://winlibs.com/ for a standalone download (instructions on how to configure in Code::Blocks are on the site) or use MSYS2's package manager pacman.
I'm trying to create a c program that work in multi linux os (ex ubuntu 16 64bit, centos 6 64bit, ubuntu 12 64bit,..) without installing the dependencies.
for example I'm using the libgcrypt.so.20 library in my program
I need a way to compile my program and import all necessary library from lib folder, so in the other host i just copy my compiled program and my lib folder that contains all my .so library
because I don't have privilege to install libgcrypt in the other host.
so if this is possible ?
I have been able to write a CMakeLists.txt file that is able to build my C project on Linux, however, I have been having a lot of trouble to build the project on windows. The cmake .. call succeeds, and Visual Studio 2017 project files are generated, but the build then fails siting:
Error LNK1104 cannot open file 'm.lib'. In the CMakeLists.txt file I am using target_link_libraries(MY_EXECUTABLE m) to try and link the math library, which works on linux, but the above error occurs on windows. After some research, it seems to me that math is handled by the mscvr library on windows, not libm as on linux, but I'm not sure how to configure the CMake file so that I can build on both operating system.
Does anyone have an idea on how I could set this up to be able to build in both environments?
Visual Studio does not need or want you to explicitly request linking the math library. You must avoid adding it as a link library when building for Windows. Instead of unconditionally doing target_link_libraries(MY_EXECUTABLE m), then, you might use:
IF (NOT WIN32)
target_link_libraries(MY_EXECUTABLE m)
ENDIF()
I have been working on some C code on a windows machine and now I am in the process of transferring it to a Linux computer where I do not have full privileges. In my code I link to several static libraries.
Is it correct that these libraries need to be re-made for a Linux computer?
The library in question is GSL-1.13 scientific library
Side question, does anyone have a pre-compiled version of the above for Linux?
I have tried using automake to compile the source on the Linux machine, but no makefile seems to be created and no error is output.
Thanks
Yes, you do need to compile any library again when you switch from Windows to GNU/Linux.
As for how to do that, you don't need automake to build GSL. You should read the file INSTALL that comes inside the tarball (the file gsl-1.16.tar.gz) very carefully. In a nutshell, you run the commands
$ ./configure
$ make
inside the directory that you unpacked from the tarball.
In the process of porting a C project from Linux to Windows
Have installed MinGW
Have compiled my shared library using a Makefile
This produces libExample.so
Now I'm trying to link this shared library to a test harness so I can see if everything is working as expected
In the harness Makefile I specify the location of the library, e.g. -LE:/libExample_dir and the name of the library -lExample
but its complaining it cannot find the library, i.e. linker is failing with cannot find -lExample - is there some difference with windows regarding .so and .dll or perhaps pathnames that I am missing?
You need to fix the make file so shared libraries are generated with a .dll extension.
If I had to guess, I'd say that while renaming the generated file is enough to make the linker happy, the loader still expects the .so extension because that's the name that was compiled in...
Using MinGw to compile C code to produce a shared library, remember to rename the output from libExample.so to libExample.dll otherwise the linker will fail to find your library