I try to build the 'lo1' Example for Mosek on MinGW. Unfortunately, it keeps returning undefined reference to ... I think I'm doing something wrong when linking the libraries. Anyone can help?
My build commands are the following:
g++ "-IC:\Program Files\Mosek\7\tools\platform\win64x86\h" "-LC:\Program Files\Mosek\7\tools\platform\win64x86\bin" -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -o "lo1.o" "lo1.cpp" "-lmosek64_7_1"
g++ "-LC:\Program Files\Mosek\7\tools\platform\win64x86\bin" -static-libgcc -static-libstdc++ -o lo1.exe "lo1.o" "-lmosek64_7_1"
Is the problem happening while building or while running the final binary?
Are you sure g++ builds a 64bit binary. Maybe you should add a -m64
g++ "-IC:\Program Files (x86)\Mosek\7\tools\platform\win32x86\h" -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -o "lo1.o" "lo1.cpp"
g++ "-LC:\Program Files (x86)\Mosek\7\tools\platform\win32x86\bin" -static-libgcc -static-libstdc++ -o lo1.exe "lo1.o" "-lmosek7_1"
Thanks for your answer. the problem happened while building.
The 64bit version did not work. Mosek 32bit works with MinGW. Above build commands were used.
Related
I was building some Cython extensions, and have to link it against a static library (it has CUDA code in them, so have to be static):
running build_ext
building 'k3lib' extension
gcc -pthread -B /home/kelvin/anaconda3/envs/torch/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/kelvin/repos/tools/include -I/home/kelvin/anaconda3/envs/torch/include/python3.8 -c main.cpp -o build/temp.linux-x86_64-3.8/main.o -O3 -march=native
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
g++ -pthread -shared -B /home/kelvin/anaconda3/envs/torch/compiler_compat -L/home/kelvin/anaconda3/envs/torch/lib -Wl,-rpath=/home/kelvin/anaconda3/envs/torch/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.8/main.o /home/kelvin/repos/tools/include/libk2.a -L/home/kelvin/repos/tools/include -lk2 -o build/lib.linux-x86_64-3.8/k3lib.cpython-38-x86_64-linux-gnu.so -static -Wl,-Bstatic -flinker-output=exec
However, Cython's g++ compile command includes the options -shared -fPIC by default. I tried a number of options at the end of the command via this setup file (the static library is at $(LOCAL_INCLUDE)/libk2.a):
includes = [os.getenv("LOCAL_INCLUDE")]
ext_modules = [
Extension("k3lib", sources=["main.pyx"],
libraries=["k2"], include_dirs=includes, library_dirs=includes, language="c++",
extra_compile_args=["-O3", "-march=native"], extra_objects=[f"{includes[0]}/libk2.a"],
extra_link_args=['-static', '-Wl,-Bstatic', '-flinker-output=exec'])
]
#extra_objects=[f"{includes[0]}/libk2.a"]
#extra_link_args=['-static']
setup(name="k3lib", ext_modules=cythonize(ext_modules, language_level="3"))
Still, g++ thinks that I want to build a shared library, and thus the error message. Is there a way to override the -shared option? I'm planning to go into Cython's files and edit them myself, but was wondering is there a simpler way?
Context: I was following this question on SO but can't replicate their success.
I'm trying to statically link glibc in order to run my application on an older OS, but when I use the -static flag I get "undefined reference" errors for other libraries I'm using that I don't get without using -static. How do I fix this issue?
My Makefile produces the following commands:
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c Utilities.cpp
gcc -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c ccvt.c
gcc -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c client.c
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c XML_Params.cpp
g++ -static -Wall -O3 -w -std=c++11 -I/storage/home/PA/libs -I/storage/home/PA/libs/xerces -fopenmp -c main.cpp
g++ -static -Wall -O3 -std=c++11 -L/storage/home/PA/libs/gsl -fopenmp -lgsl -lgslcblas -lm -L/storage/home/PA/libs/xerces -lxerces-c -o App main.o Utilities.o XML_Params.o ccvt.o client.o
After the last line I get a huge wall of errors complaining about undefined references to Xerces and gsl functions. However, if I remove the -static from the makefile, everything builds fine. What is the proper way to link these libraries when I'm using -static?
according to gcc manual:
-llibrary
It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order
they are specified. Thus, foo.o -lz bar.o searches library z after
file foo.o but before bar.o. If bar.o refers to functions in z,
those functions may not be loaded.
Move -lxerces after *.o might solve your problem.
I think you don't need to add -static except for the last line, correct me if i'm wrong.
I am new to C++ and learning RTI DDS at the moment by compiling their examples. I am currently using their make files but I want to learn how to compile individual files using gcc directly. The make files first compiles objects and links them together as per below.
g++ -DRTI_UNIX -DRTI_LINUX -DRTI_64BIT -m64 -O2 -o objs/x64Linux3gcc4.8.2/HelloPublisher.o -Isrc -Isrc/idl -I/opt/rti_connext_dds-5.2.3/include -I/opt/rti_connext_dds-5.2.3/include/ndds -c src/HelloPublisher.cpp
g++ -m64 -static-libgcc -Wl,--no-as-needed objs/x64Linux3gcc4.8.2/HelloPublisher.o -o objs/x64Linux3gcc4.8.2/HelloPublisher -L/opt/rti_connext_dds-5.2.3/lib/x64Linux3gcc4.8.2 -lnddscppz -lnddscz -lnddscorez -ldl -lnsl -lm -lpthread -lrt
How can I write a single command using g++/gcc to do both?
The usual way is
g++ -o $prog -DRTI_UNIX $moreflags $file1.cpp $file2.cpp $prog.cpp $libs
You'll have to try a bit with the myriad of arguments you got since order matters.
I’m running Netbeans 7.4 on Mavericks. In order to be able to use gdb, compilation with the -ggdb flag seems to be necessary. However, even though I specify it through the Project’s Properties/Additional Options wizard, Netbeans also emits -g during compilation. Unfortunately, it turns out that this behavior has an adverse effect when the debugging session commences. Is there any way to force Netbeans not to also emit -g?
Output during compilation:
g++ -m64 -ggdb -c -g -Werror -std=c++11 -MMD -MP -MF "build/Debug/macport_GNU-MacOSX/main.o.d" -o build/Debug/macport_GNU-MacOSX/main.o main.cpp
mkdir -p dist/Debug/macport_GNU-MacOSX
g++ -m64 -ggdb -o dist/Debug/macport_GNU-MacOSX/executable build/Debug/macport_GNU-MacOSX/main.o
Alexander.Simon#oracle.com responded here [1] to set "Development Mode" to "No Flags", then specify -ggdb in the "Additional Options".
1 - https://netbeans.org/projects/cnd/lists/users/archive/2014-02/message/12
I have a warning involving /usr/local/lib/gcc/x86_64-apple-darwin10.8.0/4.6.4/libgcc.a. I was trying to compile a C++ project using a Makefile, which shows the following:
executeit: bplustree.o nonleafnode.o leafnode.o
g++ -o executeit bplustree.o nonleafnode.o leafnode.o
bplustree.o: bplustree.cpp
g++ -g -c bplustree.cpp
nonleafnode.o: nonleafnode.h nonleafnode.cpp
g++ -g -c nonleafnode.h nonleafnode.cpp
leafnode.o: leafnode.h leafnode.cpp
g++ -g -c leafnode.h leafnode.cpp
clean:
rm executeit bplustree.o nonleafnode.o leafnode.o
When I invoke "make", I get the following output in Terminal:
g++ -g -c bplustree.cpp
g++ -g -c nonleafnode.h nonleafnode.cpp
g++ -g -c leafnode.h leafnode.cpp
g++ -o executeit bplustree.o nonleafnode.o leafnode.o
ld: warning: in /usr/local/lib/gcc/x86_64-apple-darwin10.8.0/4.6.4/libgcc.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
As you can see, I have gcc version 4.6.4. I am not sure if this warning is a threat to the project working in any way, but I would like to know what this warning means and if it is a threat. It would be nice if I can do something to remove it, too. Thank you.
I have Mac OS X Version 10.6.8. The file /usr/local/lib/gcc/x86_64-apple-darwin10.8.0/4.6.4/libgcc.a has "10.8.0", and this version of gcc I installed must have screwed me over. I don't know if I can remove this warning by installing OS X 10.8.0, but I will consider this question answered for now. Thank you.