I have a boost module called arachne, when importing this module in a python script called submitArachne I get the follwoing error: Kolophon/shlib/arachne/arachne.so: undefined symbol: _ZNK5boost15program_options22error_with_option_name4whatEv
I was not able to find any documentation from boost regarding this error. Since this is a undefined symbol error, I feel like this is a compiler problem / linker problem. I set the linker flags as follows:
BOOSTLIBS = -L$(BOOSTLIB_DIR)
BOOSTLIBS += -lboost_python39 -lboost_program_options -lboost_filesystem -lboost_system
MYLIBS += $(PYTHONLIBS) $(BOOSTLIBS)
I am currently using gcc/8.3.0 and Boost/1.78.0. The python version is Python/3.9.12.
I was not able to find any possible solutions/documentation regarding this error. I hope that someone has an idea what could be going wrong here.
I already played a little bit with the linker flags but I was not able to find a solution to this unique problem.
Related
I try to use a library compiled with gcc called matlisp based on fortran code. After specifyng the f77 compiler, I could performed the autoreconf, configure and make command to obtain the file libmatlisp.so.
But when I try to use it i get a:
Error opening shared object ".../libmatlisp.so":
/usr/lib/libf2c.so.2: undefined symbol: MAIN__.
And when i perform the command ld libmatlisp.so i get:
...
libmatlisp.so: undefined reference to `idamax_'
libmatlisp.so: undefined reference to `dger_'
/usr/lib/libf2c.so.2: undefined reference to `MAIN__'
libmatlisp.so: undefined reference to `zscal_'
libmatlisp.so: undefined reference to `dscal_'
....
Is there a way to improve the situation?
I already try this solution but it does not work.
I also try to change the compiler to gfortran but i get some some run time error messages mentionning missing libraries that are part of libf2c.
Ok. I move to a more recent source of matlisp 2012 instead of 2003, and it run properly in my environment now.
I am trying to build CEF in Release mode but I get the following linker error:
AR(target)
/home/adminuser/temp/build/linux/Release/obj.target/libcef_dll_wrapper.a
LINK(target) /home/adminuser/temp/build/linux/Release/cefclient
/home/adminuser/temp/build/linux/Release/ldb.a(ldbJS.o): In function
LdbURLLoader::LoadURL(std::string)': ldbJS.cpp:(.text+0x34e):
undefined reference toCefURLRequest::Create(CefRefPtr,
CefRefPtr)' collect2: error: ld returned 1 exit
status make: *** [/home/adminuser/temp/build/linux/Release/cefclient]
Error 1
I don't get this problem when building the Debug version so I am not quite sure how to resolve it. I tried various #pragma directives to stop the compiler from optimizing out this method but to no avail.
* UPDATE *
When I remove the -DNDEBUG flag from CFLAGS_Release in the libcef_dll_wrapper.target.mk file it will build. I don't want to do this in the Release build without knowing what I'm doing though.
I am using gcc 4.8.2.
It turns out forcing the LD linker to reanalyze my libraries was the solution. The CEF application already had an elaborate scheme of makefiles that used the --start-group and --end-group indicators to do this, but the library I previously added was not included with them. I added it and linked my application without any more problems!
I have a question regarding the inclusion of boost libraries to make files. This question has been asked (and answered) multiple times in this forum and others, I could not solve my problem however using suggestions from there, since I am stuck in a much more basic stage.
I am using a ready made make file that includes the address of the boost libraries via an env file that is included in the beginning of the makefile. Thus, all I have to do is provide the correct folder of the boost libraries, however I seem to be providing the wrong address, as I get an error that the boost libraries could not be found:.
Demo_00.cpp:(.text+0x28): undefined reference to `boost::mpi::environment::environment(int&, char**&, bool)'
Demo_00.cpp:(.text+0x34): undefined reference to `boost::mpi::communicator::communicator()'
Demo_00.cpp:(.text+0x40): undefined reference to `boost::mpi::communicator::rank() const'
Demo_00.cpp:(.text+0x55): undefined reference to `boost::mpi::communicator::rank() const'
Demo_00.cpp:(.text+0x8b): undefined reference to `boost::mpi::environment::~environment()'
Demo_00.cpp:(.text+0xb3): undefined reference to `boost::mpi::environment::~environment()'
collect2: ld returned 1 exit status
The specific part of the env file looks like this:
BOOST_INCLUDE=-I./home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/
BOOST_LIB_DIR=-L./home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/stage/lib
BOOST_LIBS=-lboost_mpi-xgcc42-mt -lboost_serialization-xgcc42-mt -lboost_system-xgcc42-mt -lboost_filesystem-xgcc42-mt
My questions:
In the template file of the env file, the first address ended with '.../boost_1_54_0/include', my boost folder does not have an include folder however (there are some further within the folder only). Is this a problem?
Do I need to make any adjustment to BOOST_LIBS?
Is there maybe a simple way of identifying the correct addresses using cmake? I worked my way through the cmake documentary but did not quite get how this would be implemented.
Also: I have just tried to 'compile+link' by hand, which only worked for the compiling part but not for linking. Here is the compiling:
/home/user/Documents/RHPC_2.0/INSTALLATION/mpich2-1.4.1p1/bin/mpicxx -c -I/home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/ -o Demo_00.o Demo_00.cpp
Here is the Linking part, which did not work
/home/user/Documents/RHPC_2.0/INSTALLATION/mpich2-1.4.1p1/bin/mpicxx -L/home/user/Documents/RHPC_2.0/INSTALLATION/boost_1_54_0/stage/lib/ Demo_00.cpp -lboost_mpi-xgcc42-mt -lboost_serialization-xgcc42-mt -lboost_system-xgcc42-mt -lboost_filesystem-xgcc42-mt
After this command I get the following error:
/usr/bin/ld: cannot find -lboost_mpi-xgcc42-mt
/usr/bin/ld: cannot find -lboost_serialization-xgcc42-mt
/usr/bin/ld: cannot find -lboost_system-xgcc42-mt
/usr/bin/ld: cannot find -lboost_filesystem-xgcc42-mt
collect2: ld returned 1 exit status
It seems, here the problem lies with the these last 4 files and not the entire boost folders. The above folders /usr/bin/ld are also not existent to my knowledge.
I appreciate your help and again my apologies for bringing up this topic yet again.
Thanks,
Tartaglia
Whatever is passed to -I should be pointing to the folder having boost/*hpp files under it (say boost/shared_ptr.hpp).
Whatever is passed to -L should be the folder where all of those passed to -l reside (when you say -lthename the respective file name is libthename.so).
Also these BOOST_* environment variables should be concatenated to the compiler/linker command line (I assume that is already happening automatically in your case).
I have been writing some python extension modules with cython. The extensions I've written build and work well. Then, I wanted to use typed memoryviews, when accessing my numpy arrays, as they seem to have several advantages http://docs.cython.org/src/userguide/memoryviews.html
However, as soon as I use a memoryview in my cython code I will get an error when building the extension. For example, if I add this test line:
cdef double[:, ::1] X = np.zeros((100, 100))
to an existing, working cython extension. I will get the following errors:
C:\MinGW\bin\gcc.exe -shared -s build\temp.win32-2.7\Release\image_box.o build\temp.win32-2.7\Release\image_box.def -Lc:\python27\libs -Lc:\python27\PCbuild -lp
ython27 -lmsvcr90 -o x:\ARframework\python\image_ops\image_box.pyd
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0xe23): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x3318): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4c81): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4d37): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10767): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10793): undefined reference to `___sync_fetch_and_sub_4'
collect2.exe: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
I've tried to add -march=i486 to the gcc line, as suggested in this post:
undefined reference to sync_fetch_and_add_4
but that didn't solve the problem. For that matter, I also tried -march=i586 and -march=pentium without success.
Any idea what's going on here?
My platform is Windows 7, mingw version is 4.70, Cython version is 0.17.1
Thanks
I found a solution.
Actually, the gcc flag -march=i486 does solve the problem! However, when I tested it in the console I just applied it to the gcc line for the link step (that's where I got the errors) and as it didn't solve the problem I thought it just didn't work.
In fact, I need to use -march=i486 both in the compile and link steps, then there is no errors anymore.
As to how to include these flags when I build the extension, I have tried to add
import os
os.environ['LDFLAGS'] = '-march=i486'
os.environ['CFLAGS'] = '-march=i486'
to the setup.py but it didn't seem to work.
So I have modified the c:\python27\Lib\distutils\cygwinccompiler.py to include these flags in the compile and link steps. Not sure if this is very elegant way of setting these flags. Any alternatives are welcome!
I am stumped by what seems to be a problem that should be easy to diagnose and fix. I have a C++ source file that makes use of the CUDA Driver API. When I compile it using nvcc, the executable is produced and works without problems. However, when I try to compile it using g++, the linker complains about undefined references to symbols that are in /usr/lib/libcuda.so:
undefined reference to cuDeviceGet'
... undefined reference tocuDeviceComputeCapability'
... undefined reference to cuDeviceGetName'
... undefined reference tocuDeviceTotalMem_v2'
... undefined reference to cuDeviceGetAttribute'
... undefined reference tocuDeviceGetAttribute'
... undefined reference to cuDeviceGetAttribute'
... undefined reference tocuDeviceGetAttribute'
I tried to ensure that /usr/lib is included in the library path (by supplying the flags -L/usr/lib, -lcuda, and adding /usr/lib to $LIBRARY_PATH). However, the problem still persists. I am sure that /usr/lib/libcuda.so contains the symbols that the linker is complaining about:
$ nm -D /usr/lib/libcuda.so | grep cuDeviceGet
00000000000be410 T cuDeviceGet
00000000000bf120 T cuDeviceGetAttribute
00000000000d2e10 T cuDeviceGetByPCIBusId
00000000000be200 T cuDeviceGetCount
00000000000bdfa0 T cuDeviceGetName
00000000000d2bb0 T cuDeviceGetPCIBusId
00000000000bf380 T cuDeviceGetProperties
I find it strange that nvcc successfully compiles the file, but g++ does not. Do you have any idea as to how I can fix this problem?
Thank you very much for your help!
Ok, the reason I was not able to compile the file was because the -lcuda flag has to come after the filename. Otherwise, it won't work... a large, prominent warning with the compiler telling me this information would have been much appreciated. Well, that was a waste of two hours.