I wrote a program that is using OpenSSL and I'm trying to compile it to executable for inwdows.
The command I'm using to compile is:
gcc -g -Ifolder1/include -Iopenssl/include -Ifolder2 -c folder1/lib/functions.c -o folder1/lib/functions.o
gcc -g -Ifolder1/include -Iopenssl/include -Ifolder2 -o myprog.exe main.o folder1/lib/myfiles.o folder1/lib/plus.o folder1/lib/functions.o -Lopenssl/windows/static -lcrypto
This works for linux but for windows i get
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lcrypto
Any idea what is the corresponding flag for -lcrypto for linux?
The problem was that in path openssl/windows/static i had a library with the suffix *.lib and seems like gcc doesnt recongnize it as a library.
resolved when i change it to *.a suffix
Related
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised
I need to build this Lua module and to be able to use it in another application that already has Lua core included. Module will be loaded via 'require'.
I'm using MinGW x64 on Windows 10. I successfully built Lua 5.2 with it, extracted lua.dll file and renamed it into liblua.dll.a.
Then I built the module using following Makefile:
CC = x86_64-w64-mingw32-gcc
LUA_INCDIR=$(STAGING_DIR)/usr/include
utf8.dll: lutf8lib.o
$(CC) -m64 -O -shared -fpic lutf8lib.c -o utf8.dll -llua
lutf8lib.o: lutf8lib.c
$(CC) -O2 -fpic -c -DLUA_BUILD_AS_DLL lutf8lib.c -I$(LUA_INCDIR)
The problem is file size, it's 420kb and it definetely includes Lua core (I got 'multiple VMs' error). I need to build the module without including the core.
Previously I installed usual MinGW (x86) and used following Makefile:
CC = gcc
LUA_INCDIR=$(STAGING_DIR)/usr/include
utf8.dll: lutf8lib.o
$(CC) -m32 -shared lutf8lib.c -o utf8.dll -llua
lutf8lib.o: lutf8lib.c
$(CC) -fPIC -c lutf8lib.c -I$(LUA_INCDIR)
And got 97kb file without Lua core. Unfortunately I specifically need x64 file.
UPD: I tried to build the same module using MSVC, but it seems that IDE changes luaopen_utf8 function name. If I'll add this to fix it:
int __declspec(dllexport)
IDE will include Lua core VM into DLL file. Again.
I'm seeing:
ld: in objs/AttributeValueTest.o, can't link with a main executable for architecture x86_64
When building a very simple program which has only 1 .h and 1 .cpp file.
The compile lines are:
g++ -g -I./ -I/usr/local/include -o objs/AttributeValueTest.o tp_datastruct/tests/AttributeValueTest.cpp -L/usr/local/lib -lavrocpp -lcppunit -lm
g++ -g -I./ -I/usr/local/include -o AttributeValueTest objs/AttributeValueTest.o -L/usr/local/lib -lavrocpp -lcppunit -lm
I tried to specify -arch x86_64, -arch i386 and -m32, but nothing worked (I got other errors, it was complaining that libcppunit was not in the right format).
Any idea/pointer/suggestion?
Thanks!
Very strange. I did some digging around, and saw somewhere that AttributeValueTest.o might be an executable already. I did a "file" on that AttributeValueTest.o, and sure enough, it is a ready-to-go executable. I modified my makefile to rename that .o into AttributeValueTest, and I can happily run it. Also, the executable comes with a ".dSYM" directory, which I can remove without any problem... I don't understand what is going on, but I can run my executable now...
You forgot to specify -c option to the g++ to compile a source code into object file. So it is getting compiled and linked into executable file. Then you are trying to link executable into executable, which fails. From the gcc's manual page:
-c Compile or assemble the source files, but do not link. The
linking stage simply is not done. The
ultimate output is in the form of an
object file for each source file.
By default, the object file name for a source file is made by
r> eplacing the suffix .c, .i, .s, etc.,
with .o. Unrecognized input files, not
requiring compilation or assembly, are
ignored.
I'm currently trying to compile a dynamically linked library (for a plugin system) using Windows and MinGW.
I compile each objects using this command line :
mingw-g++ -fPIC test.cpp
And the library using this line:
mingw-g++ -rdynamic -shared -Wl,-soname,test.so.1 -o test.so test.o
It doesn't work at all (using GCC with Linux, a similar line works though) : fPIC and rdynamic are ignored for some reason.
And while trying to make the library, it fails because the compiler try to link it with objects that are supposed to be resolved as I dynamically link it with the main binary.
So how do you compile this using MinGW?
Thanks :) !
-fPIC and -rdynamic are ignored because they are unused for Windows.
Also, .so is not the correct output extension for libraries on Windows.
To make a shared library for/on windows with GCC:
mingw-g++ -c file.cpp -o file.o
mingw-g++ -shared -Wl,--out-implib,libfile.a -o file.dll file.o
No more, no less.
And, documentation is always lovely to have: http://www.mingw.org/wiki/sampleDLL