I have receive a makefile from another source. I am supposed to cross-compile on my machine (x86_64, GCC 5.3) it to use on an arm-embedded device (host). I tried to compile with a tool chain (arm_64, GCC7.5) which i installed in my /opt directory by making the following changes (those that are remarked out #) in the makefile of the project
#SYSROOT?=$(shell $(CXX) --print-sysroot)
SYSROOT= /opt/yocto/sysroots/
CXXFLAGS= -std=c++11 -I src/
CCFLAGS= -std=c++11 -I src/
#CXX_LDFLAGS= -L /usr/local/aarch64-linux/lib/ -lpthread -pthread
CXX_LDFLAGS= -L $(SYSROOT)/aarch64-yocto-linux/lib -lpthread -pthread
all: foo
foo: src/foo.cpp
$(CXX) -std=c++11 -g -o $# $^ $(CXX_LDFLAGS)
clean:
rm -rf .objs
However when the code was compiled, it could not be run on host device(arm) and there was warning during make that say along lines of skipping incompatible binaries.
I perform file on the compiled application. It read
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=99376bcc919a48224e063ec6c6892e1979b5d94e, not stripped
It is clear to me that I have compiled it with my native compiler,libraries etc.
What should i do in this case:
must i do the following before compilation or making the folder
./configure -build xxxxx -host yyyyyy
there is some files, called environment files (full of export settings) in the tool chain directory that seems to be like some configuration settings being exported. Should i use this file? or how should i use them
Regards
Related
Just a disclaimer I'm not too experienced with Make files, so forgive me if the answer is simple! I have a Make file that compiles several .cpp & .h files into .o files, and then produces an executable. I am using g++ as the compiler currently. I'd like to adapt this file to allow for openmpi multi-core computing. To note: I'm on a Windows 11 x 64 architecture, using Cygwin to build run this cpp code. I also would like this to run on MacOS systems as well.
In particular, the parallelization macros are only in 1 .cpp file, what I'd consider the 'main' file of this project (mag_spec_tracker.cpp). I don't know if that makes a difference here but thought it could be useful to let be known.
My current Makefile is below - note I added a line to try and grab the mpicc compile flags, but I am unsure on how to use them here.
IDIR = include
CXX = g++
CXXFLAGS = -I$(IDIR) -std=c++17
ODIR = obj
_DEPS = my_functions.h particle.h beam.h threevector.h threematrix.h screen.h magnet.h
DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))
_OBJ = my_functions.o particle.o beam.o mag_spec_tracker.o screen.o magnet.o
OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))
$(ODIR)/%.o: %.cpp $(DEPS)
$(CXX) -c -o $# $< $(CXXFLAGS)
run: $(OBJ)
$(CXX) -o $# $^ $(CXXFLAGS)
.PHONY: clean
clean:
rm -f $(ODIR)/*.o *~ core $(IDIR)/*~
I have tried adding lines into the Makefile to get the mpi compile flags based on other reference I've found online, but was unsure how to adapt my current code to add these flags to allow for correct usage of openmpi. The lines I added to grab compile flags were:
MPI_COMPILE_FLAGS = $(shell mpicc --showme:compile)
MPI_LINK_FLAGS = $(shell mpicc --showme:link)
Thank you in advance!
Update (12/6/2022)
Responding to the comment from Matzeri ('for opempi the compiler is mpicc not gcc. for c++ is mpicxx not g++'), I replaced 'g++' in my makefile with 'mpicxx' and recieved the following error:
$ make
mpicxx -c -o obj/mag_spec_tracker.o mag_spec_tracker.cpp -Iinclude -std=c++17
mpicxx -o run obj/my_functions.o obj/particle.o obj/beam.o obj/mag_spec_tracker.o obj/screen.o obj/magnet.o -Iinclude -std=c++17
C:/Users/Jason/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmpi_cxx: No such file or directory
C:/Users/Jason/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmpi: No such file or directory
C:/Users/Jason/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopen-rte: No such file or directory
C:/Users/Jason/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopen-pal: No such file or directory
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:19: run] Error 1
I notice that its looking for an ld executable in 'mingw64'. I tried removing that directory (previously I had installed mingw64, but switched to cygwin), and got the following error:
$ make
mpicxx -o run obj/my_functions.o obj/particle.o obj/beam.o obj/mag_spec_tracker.o obj/screen.o obj/magnet.o -Iinclude -std=c++17
--------------------------------------------------------------------------
The Open MPI wrapper compiler was unable to find the specified compiler
g++ in your PATH.
Note that this compiler was either specified at configure time or in
one of several possible environment variables.
--------------------------------------------------------------------------
make: *** [Makefile:19: run] Error 1
I also added c:\cygwin\bin to my environment paths, and this issue still occurs. I confirmed that mpicxx is in that bin folder.
Any ideas?
I'm currently developing a C++ application which will reference multiple *.so libraries, each containing code for different machines - written in C.
I also have one shared object containing code from a custom namespace Utilities, which (as the name implies) contains basic utilities useful for the application (written in C++, like the rest of the application).
Currently, utilities.so is the only (custom) library referenced by the application.
The application compiles and links just fine, however executing it on the target hardware display the following error: bin/updater_v4test: error while loading shared libraries: ../../../bin/device_modules/utilities.so.1.0.0: cannot open shared object file: No such file or directory
When calling LDD on said application, the following output is shown: ../../../bin/device_modules/utilities.so.1.0.0 => not found
I've written a script which (upon make exiting without errors) collects all SOs and pushes them in to the /lib/ directory on the target hardware; meaning that upon each successful build of the application (whether in part or entirely), the updated files are pushed to the correct directory on the target hardware.
In an attempt to mimic other libraries I've used (e.g. zlib), I've attempted to create a symlink to the library file, with no luck (utilities.so.1.0.0 is the symlink, utilities.so is the actual SO).
utilities.so.1.0.0 --> utilities.so
At the moment I'm at a loss, and I can't waste much more time in trying to figure this out myself.
Below is an excerpt from the utilities Makefile:
include ../../common/user.mk
LIB_DIR=../../../libs/lib/powerpc-linux-gnu
CFLAGS=-Wall -ggdb -I../../libs/include -I../../common -lpthread -lddc -std=c++0x -I../../libs/include/zlib
LDFLAGS=../../libs/lib/powerpc-linux-gnu/libcurl.so.4 ../../libs/include/minizip/.libs/libminizip.so.1.0.0 \
-L ../../libs/lib \
-L ../../libs/lib/powerpc-linux-gnu \
-Wl,-rpath-link,../../libs/lib/powerpc-linux-gnu \
-lrt -lddc -lpthread -shared
BIN_DIR=../bin
CANONICAL_BIN_DIR := $(shell readlink -f $(BIN_DIR))
CANONICAL_CUR_DIR := $(shell readlink -f "./")
COMP_OBJECTS := $(wildcard *.cpp)
OBJECTS := $(patsubst %.cpp,%.o,$(wildcard *.cpp))
all: objects utilities.so
-cp --parents utilities.so $(GLOBAL_BIN_LIB)
-ln -s utilities.so utilities.so.1.0.0
-mv utilities.so.1.0.0 $(GLOBAL_BIN_LIB)
# -cp --parents *.h $(GLOBAL_HEADER_DIR)
-rm -f utilities.so
-rm -f *.o
for header in $(wildcard *.h); do \
echo $$header; \
ln -s $(CANONICAL_CUR_DIR)/$$header $(GLOBAL_HEADER_DIR)/$$header; \
done;
#printf "########## BUILT $^ ##########\n\n"
utilities.so: $(OBJECTS)
${CXX} $^ -o $# ${LDFLAGS}
objects: $(COMP_OBJECTS)
${CXX} -c $^ ${CFLAGS}
And now an excerpt from the application Makefile.
Here I've added a reference to the library in the linker flags, the header files are all included in from one directory.
include ../../../common/user.mk
LIB_DIR=../../../libs/lib/powerpc-linux-gnu
CFLAGS=-Wall -ggdb -I../../../libs/include -I${COMMON_DIR} -lpthread -lddc -std=c++0x -I../../../libs/include/zlib -I${HEADER_DIR}
LDFLAGS=../../../libs/lib/powerpc-linux-gnu/libcurl.so.4 ../../../libs/include/minizip/.libs/libminizip.so.1.0.0 ../../../bin/device_modules/utilities.so.1.0.0 \
-L ../../../libs/lib \
-L ../../../libs/lib/powerpc-linux-gnu \
-Wl,-rpath-link,../../../libs/lib/powerpc-linux-gnu \
-lrt -lddc -lpthread -L ${SO_DIR}
BIN_DIR=../bin
CANONICAL_BIN_DIR := $(shell readlink -f $(BIN_DIR))
CANONICAL_CUR_DIR := $(shell readlink -f "./")
all: test_update.bin
-cp --parents test_update.bin $(BIN_DIR)
-ln -s $(CANONICAL_BIN_DIR)/test_update.bin $(GLOBAL_BIN_APP)/test_update.bin
-rm -f *.bin
#printf "########## BUILT $^ ##########\n\n"
test_update.bin: main.o updaterdelegate.o commonfunctions.o tinyxml.o
${CXX} $^ -o $# ${LDFLAGS}
####################
# Required Files #
####################
main.o: Main.cpp
${CXX} -c $^ -o $# ${CFLAGS}
updaterdelegate.o: UpdaterDelegate.cpp
${CXX} -c $^ -o $# ${CFLAGS}
commonfunctions.o: $(shell python -c "import os.path; print os.path.relpath('${IMPL_CMN_FUNC}'.replace('\"', ''), '${CANONICAL_CUR_DIR}'.replace('\"', ''))")
${CXX} -c $^ -o $# ${CFLAGS}
tinyxml.o: $(shell python -c "import os.path; print os.path.relpath('${IMPL_TXML}'.replace('\"', ''), '${CANONICAL_CUR_DIR}'.replace('\"', ''))")
${CXX} -c $^ -o $# ${CFLAGS}
####################
# /Required Files #
####################
Just for gits and shiggles, I'll add the build output of the utilities.so and application.
utilities.so:
(Clean ommitted)
=============== CLEAN COMPLETE... BUILDING... ===============
make: Entering directory `~/_workspace/upv4/common/utils'
powerpc-linux-gnu-g++ -c ArgumentHandling.cpp Extensions.cpp Logging.cpp -Wall -ggdb -I../../libs/include -I../../common -lpthread -lddc -std=c++0x -I../../libs/include/zlib
ArgumentHandling.cpp: In member function ‘void Utilities::ArgumentHandler::freeMemory()’:
ArgumentHandling.cpp:136: warning: deleting ‘void*’ is undefined
powerpc-linux-gnu-g++ ArgumentHandling.o Extensions.o Logging.o -o utilities.so ../../libs/lib/powerpc-linux-gnu/libcurl.so.4 ../../libs/include/minizip/.libs/libminizip.so.1.0.0 -L ../../libs/lib -L ../../libs/lib/powerpc-linux-gnu -Wl,-rpath-link,../../libs/lib/powerpc-linux-gnu -lrt -lddc -lpthread -shared
cp --parents utilities.so """~/_workspace/upv4""/bin/device_modules"
ln -s utilities.so utilities.so.1.0.0
mv utilities.so.1.0.0 """~/_workspace/upv4""/bin/device_modules"
rm -f utilities.so
rm -f *.o
for header in ArgumentHandling.h Enumerations.h Extensions.h Logging.h; do \
echo $header; \
ln -s ~/_workspace/upv4/common/utils/$header """"~/_workspace/upv4""/bin/device_modules"/headers"/$header; \
done;
ArgumentHandling.h
Enumerations.h
Extensions.h
Logging.h
########## BUILT objects utilities.so ##########
make: Leaving directory `~/_workspace/upv4/common/utils'
=============== BUILD COMPLETE... PARSING... ===============
========== Warnings ==========
Total: 1
ArgumentHandling.cpp:136: warning: deleting ‘void*’ is undefined
========== Errors ==========
Total: 0
test_update.bin:
(Clean ommitted)
=============== CLEAN COMPLETE... BUILDING... ===============
make: Entering directory `~/_workspace/_workspace/upv4/test/app/src'
powerpc-linux-gnu-g++ -c Main.cpp -o main.o -Wall -ggdb -I../../../libs/include -I"""~/_workspace/_workspace/upv4""/common" -lpthread -lddc -std=c++0x -I../../../libs/include/zlib -I"""""~/_workspace/_workspace/upv4""/bin/device_modules"/headers""
powerpc-linux-gnu-g++ -c UpdaterDelegate.cpp -o updaterdelegate.o -Wall -ggdb -I../../../libs/include -I"""~/_workspace/_workspace/upv4""/common" -lpthread -lddc -std=c++0x -I../../../libs/include/zlib -I"""""~/_workspace/_workspace/upv4""/bin/device_modules"/headers""
powerpc-linux-gnu-g++ -c ../../../common/commonFunctions.cpp -o commonfunctions.o -Wall -ggdb -I../../../libs/include -I"""~/_workspace/_workspace/upv4""/common" -lpthread -lddc -std=c++0x -I../../../libs/include/zlib -I"""""~/_workspace/_workspace/upv4""/bin/device_modules"/headers""
powerpc-linux-gnu-g++ -c ../../../common/xmlreader/tinyxml2.cpp -o tinyxml.o -Wall -ggdb -I../../../libs/include -I"""~/_workspace/_workspace/upv4""/common" -lpthread -lddc -std=c++0x -I../../../libs/include/zlib -I"""""~/_workspace/_workspace/upv4""/bin/device_modules"/headers""
powerpc-linux-gnu-g++ main.o updaterdelegate.o commonfunctions.o tinyxml.o -o test_update.bin ../../../libs/lib/powerpc-linux-gnu/libcurl.so.4 ../../../libs/include/minizip/.libs/libminizip.so.1.0.0 ../../../bin/device_modules/utilities.so.1.0.0 -L ../../../libs/lib -L ../../../libs/lib/powerpc-linux-gnu -Wl,-rpath-link,../../../libs/lib/powerpc-linux-gnu -lrt -lddc -lpthread -L """"~/_workspace/_workspace/upv4""/bin/device_modules""
cp --parents test_update.bin ../bin
ln -s ~/_workspace/_workspace/upv4/test/app/bin/test_update.bin """~/_workspace/_workspace/upv4""/bin"/test_update.bin
ln: failed to create symbolic link `~/_workspace/_workspace/upv4/bin/test_update.bin': File exists
make: [all] Error 1 (ignored)
rm -f *.bin
########## BUILT test_update.bin ##########
make: Leaving directory `~/_workspace/_workspace/upv4/test/app/src'
=============== BUILD COMPLETE... PARSING... ===============
========== Warnings ==========
Total: 0
========== Errors ==========
Total: 0
The build script is custom, I built it myself to rid myself of the entire make output when I don't need it, and it parses out all the errors and warnings.
Due to the issue, I have turned make output back on.
Did I miss something during compilation/linking of the library, or is something going wrong during the linking of the application?
I'm inclined to say it's during compilation/linking of the library - although I don't know what exactly is going wrong, as everything is compiling and linking just fine.
Why is the application looking for the .so file in a path it can't possibly have?
I also made sure that the .so files are found with the $PATH variable, so the application should be able to find them.
The system normally searches for shared objects in a fixed set of directories. You can handle around this by defining the environment variable LD_LIBRARY_PATH and adding the directory where you install the shared libraries into.
Or you can add those libraries to some of the standard libraries directories and execute ldconfig -a to update the cache of shared libraries.
See ldconfig(8), for more info.
edit
There are two mechanisms to load a shared object.
The first is the normal library loading mechanism, that specifies what has to be loaded at start executable time, and implies linking your executable with the shared objects. This is what you do in your Makefile. You specify the shared executables, and the ld.so.xxx shared object (which is linked to your application when you are dynamically linking it) loads and follows all the unresolved identifiers to find a place for them in the virtual address space. The ld.so.xxx object uses the /etc/ld.so.cache file, that is just a hash table with the directories and shared executables available to be loaded this way. That file is indexed by what is called the soname (which is something useful to allow different versions of the same library to coexist in the same system) and normally maps to the last versioned shared found in the list of directories listed in the file /etc/ld.so.conf (this is static information to accelerate the process of loading libraries and is generated at each boot of the system). If the shared was found at link time (this mechanism is not used by ld, but only to load the libraries at program start time) to have a soname, then that soname is searched in the /etc/ld.so.cache to find the final file that has to be loaded. This cache is built on each boot of the system, so you don't have to cope with that, but only if you don't want to reboot and you install a new library for system use. It is important to note that shared objects must be given sonames for this to work, and that the list of directories in the file /etc/ld.so.conf are the only directories used to search for files. This means that for a standard library to be usable, you need to put it in one of this directories (or add the directory to the list in /etc/ld.so.conf) and then execute ldconfig -a to rebuild the cache and let it include a reference for the file under that soname.
The other way it to add to the list of search places a list in the form of a PATH variable. The variable is LD_LIBRARY_PATH so, in case you have your shared objects in ${HOME}/libs, you can add this line to your .profile:
export LD_LIBRARY_PATH=${HOME}/libs
or
setenv LD_LIBRARY_PATH ${HOME}/libs
this allows your library to live outside of the standard directories, but think twice, as this is a far less efficient way to load a file (as it involves processing a list of directories to look for the final shared objects, while the previous approach is direct, you ask for the file matching the soname that ld.so.xxx asks for, only one search, only one step)
The second is to use a library function dlopen(3) that allow you to load a shared object and do some housekeeping before calling anything inside. The dl library allows you to search for a symbol in the shared executable and then decide if you interpret it as data or a jump target. dlopen() just opens and loads into the virtual address space a shared object. It resolves the dependencies (if requested to) and is the more flexible way (but it is also nontransparent) to load unknown code for execution. This is the way plugins normally work. You decide in a config file, or dynamically what to load, and then you load it. The program doesn't have to know previously the symbol table of what you are dealing with and you are free to implement whatever you want in the module you are loading.
All of these methods work with ELF binaries, so you have a lot of freedom, but also a lot of complexity on it.
more...
As i've seen from your compilation:
you are including -l in the compile only commands, the libraries are only needed if you are linking an executable, don't put libraries in the compile phase.
for a library to be searched and selected by the linker, it has to be named as lib<name>.so (without the version info at the end) so this means that you normally find three names for a standard library (let me use the math library -lm as an example):
/usr/lib/libm.so.3.2.8 # this is the ELF file with the library contents.
/usr/lib/libm.so.3 -> libm.so.3.2.8 # this is the soname used to create the library.
/usr/lib/libm.so -> libm.so.3 # this is the actual file the ld(1) program searches for when using -lm.
those links have to be created, as the system normally doesn't. This is part of the installation procedure for a shared library. The soname link allows you to have different versions of a library and detect which one of them will be used at runtime (all must be compatible so you can interchange, when you make an incompatible modification, then you have to change the soname, so the system doesn't get confused on loading)
It is very important to know that the ld(1) program only selects a library if it is called lib<name>.so, with no version info. Indeed, the compiler first searchs for lib<name>.so, then for lib<name>.a, then it complains.
It is very important to put -L places to search for libraries before any -l option that will use those directories in the linking parameters.
You only need to run ldconfig -a and install the library in a system directory if you are not going to use the LD_LIBRARY_PATH mechanism. (this mechanism doesn't work for root account, for obvious reasons :))
Expecting this added comments give some light to the process.
I'm trying to compile C++ project with gcc-make command but program giving this error. I already compiled Crypto++ and added include and lib folder but I dont know how to add this dir to gcc.
What should I do for fixing this "-lcrytopp" error?
I'm using makefile and this is line of 33-34.
$(TARGET): build $(OBJECTS)
$(CC) $(OBJECTS) -o $(TARGET) -lcryptopp
Error:
D:\Osman\CnC RA2\Mix\ccmix-crypto\ccmix-crypto>make
g++ src/mix_db_gamedb.o src/mix_db_gmd.o src/mix_header.o src/mix_db_lmd.o
src/mixid.o src/ccmix.o src/mix_file.o -o build/ccmix -lcryptopp
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32
/bin/ld.exe: cannot find -lcryptopp
collect2.exe: error: ld returned 1 exit status
Makefile:34: recipe for target 'build/ccmix' failed
make: *** [build/ccmix] Error 1
Crypto++ directory:
Compile error:
You haven't added the directory containing the library to your link line. It should be something like -Lxxx where xxx is the path to the directory containing the cryptopp library:
$(TARGET): build $(OBJECTS)
$(CC) $(OBJECTS) -o $(TARGET) -Lxxx -lcryptopp
(replace xxx with the directory containing the cryptopp library)
What should I do for fixing this "-lcrytopp" error?
When working from the Crypto++ build directory on Unix compatibles, the project does not use include and lib (as your picture shows). Everything is placed in the root directory (as your picture shows).
If you perform a make install, then the directories are setup, but it appears you did not install. I should also say that MinGW is not usually tested anymore because the project is abandoned, so I'm not sure where make install actually installs to on MinGW.
To fix the compile error, tweak your make recipe:
$(TARGET): build $(OBJECTS)
$(CXX) $(CXXFLAGS) -I. $(OBJECTS) ./libcryptopp.a -o $(TARGET)
The recipe above uses CXX (C++ compiler) rather than CC (C compiler); it uses CXXFLAGS (which should be something like -DNDEBUG -g2 -O2); it calls out the header path (-I.); and it links to the static library (./libcryptopp.a). Linking to the static library will avoid your next set of problems.
You can follow MadScientist's advice and use -LXXX and -lcryptopp. You might even add a runpath with -Wl,-rpath,D:\Osman\CnC RA2\Mix\ccmix-crypto\ccmix-crypto. But at the end of the day, using -L and -l causes a fair amount of trouble. Avoid the future problems by statically linking libcryptopp.a.
Also see GNUmakefile | Compiling and Linking on the Crypto++ wiki.
Your fist picture shows ipch and Win32 directories. That usually means you built the Crypto++ library with Visual Studio. Now you are building a program with GCC. You should not mix and match compilers like that. Nothing good will come of it.
I've got a project which consists of many files in subdirectories. I have a simple Makefile which handles the compilation. It looks like this:
CC = g++ -Wall -ansi -pedantic
all:
$(CC) -O2 engine/core/*.cpp engine/objects3d/*.cpp engine/display/*.cpp engine/io /*.cpp engine/math/*.cpp engine/messages/*.cpp *.cpp -o project1 -lGL -lGLU -lX11 `sdl-config --cflags --libs`
clean:
#echo Cleaning up...
#rm project1
#echo Done.
However I need to migrate to SCons. I have no idea how to write a script that would automatically handle finding all the *.cpp files in subdirectories and included them in the compilation process.
This is how to do what you have in your Makefile in SCons. You should put this Python code in a file at the root of the project called SConstruct, and just simply execute scons. To clean, execute scons -c
env = Environment()
env.Append(CPPFLAGS=['-Wall', '-ansi', '-pedantic', '-O2', '-lGL', '-lGLU', '-lX11'])
# Determine compiler and linker flags for SDL
env.ParseConfig('sdl-config --cflags')
env.ParseConfig('sdl-config --libs')
# Remember that the SCons Glob() function is not recursive
env.Program(target='project1',
source=[Glob('engine/core/*.cpp'),
Glob('engine/objects3d/*.cpp'),
Glob('engine/display/*.cpp)',
Glob('engine/io/*.cpp'),
Glob('engine/math/*.cpp'),
Glob('engine/messages/*.cpp'),
Glob('*.cpp')])
Here is a link for using SDL with SCons.
And here is info on the SCons ParseConfig() function.
I figured it wouldn't work, but i just uploaded my program file from local machine to a new instance on Amazon EC2. Than tried to run it:
[ec2-user#domU-12-31-39-14-2A-1A ~]$ ./webserver.net
-bash: ./webserver.net: /lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
Apparently there is no /lib/ld-linux-x86-64.so.2. It is a 64 bit Instance.
How would i compile/link on local machine targeting the EC2 instance. I don't want to build it on the instance.
My Makefile
OBJECTS= ./obj/hello.o
LDFLAGS = -L/usr/lib -lwt -lwthttp
./bin/webserver.net : $(OBJECTS)
g++ -o ./bin/webserver.net $(OBJECTS) $(LDFLAGS)
./obj/hello.o : ./src/hello.cpp
g++ -c ./src/hello.cpp -o ./obj/hello.o
.PHONY: clean
clean:
-rm -f obj/*.o bin/webserver.net core *~ src/*~
Update Statically linked file. There were undefined references until I added each library manually and in the right order. Is this necessary? or am I doing it wrong?
g++ -static -pthread -o ./bin/out.net ./obj/hello.o -lwthttp -lwt -lboost_thread -lboost_system -lboost_program_options -lboost_random -lboost_signals -lboost_filesystem -lboost_regex -lboost_serialization -lboost_date_time -lssl -lcrypto -lz -ldl
An ugly but simple solution might be to link statically your program.
A more elaborate solution could be to mimic the environment of the EC2 instance in e.g. a chroot-ed environment on your local machine.
In between you might copy the EC2's /usr/include and /usr/lib/libc.so... etc.. locally, but that is risky.
Perhaps also you could compile locally, and link on the EC2... (but that might not work)
A dynamic library lib*.so can be built with dependencies on other dynamic libraries. (for instance, try ldd /usr/lib/libgtk-3.so or ldd on some other system *.so library on your machine).
A static library lib*.a is essentially only a mix of *.o object files and don't know its dependencies.
So when linking statically, you need indeed to link all the libraries, in the correct order.