Cygwin: bad reloc address linking la - python

I am trying to install this python package on my cygwin(last available version) setup, using gcc and no windows/microsoft components at all. The package has many dependencies so it can take a while for you to try to install it. I guess the error is generic and you don't require to replicate the issue to provide insights on how to fix it.
I have found this error for several(all?) .la libraries on the package:
Making all in centrality
make[4]: Entering directory '/cygdrive/d/gdrive/Thesis/tech/urv tech/graph-tool-2.2.31/src/graph/centrality'
CXX graph_betweenness.lo
CXX graph_centrality_bind.lo
CXX graph_closeness.lo
CXX graph_eigentrust.lo
CXX graph_eigenvector.lo
CXX graph_hits.lo
CXX graph_katz.lo
CXX graph_pagerank.lo
CXX graph_trust_transitivity.lo
CXXLD libgraph_tool_centrality.la
/usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: warning: --export-dynamic is not supported for PE targets, did you mean --export-all-symbols?
.libs/graph_betweenness.o:graph_betweenness.cc:(.text+0x182b): undefined reference to `graph_tool::GraphInterface::GetNumberOfVertices()'
.libs/graph_betweenness.o:graph_betweenness.cc:(.text+0x19bd): undefined reference to `graph_tool::GraphInterface::GetNumberOfVertices()'
.libs/graph_betweenness.o:graph_betweenness.cc:(.text+0x1a68): undefined reference to `graph_tool::ValueException::ValueException(std::string const&)'
.libs/graph_betweenness.o:graph_betweenness.cc:(.text+0x1a87): undefined reference to `graph_tool::ValueException::~ValueException()'
.libs/graph_betweenness.o:graph_betweenness.cc:(.text+0x1ad1): undefined reference to `graph_tool::ValueException::ValueException(std::string const&)'
/usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: .libs/graph_betweenness.o: bad reloc address 0x6 in section `.text$_ZN5boost16exception_detail10clone_baseD1Ev[__ZN5boost16exception_detail10clone_baseD1Ev]'
collect2: error: ld returned 1 exit status
Makefile:474: recipe for target 'libgraph_tool_centrality.la' failed
As I see .lo files are built, probably not correctly, and when it comes to generate the .la file is when I get the 'bad reloc address' error. In other words, my assumption is that because the .lo files are not correctly generated the .la built fails.
Doing some research I have found this bug reported and fixed back in 2009:
https://www.mail-archive.com/bug-binutils#gnu.org/msg07150.html
Based on it, I understand that an approach to try to fix the problem would be to replace the -export-dynamic flag by -export-all-symbols in the configure file the python library uses to install itself. There are two files that I modify: configure and [configure.ac][2]
Configure has this kind of export-dynamic mentions, related to other settings:
export_dynamic_flag_spec_CXX='${wl}--export-dynamic'
Configure.ac has this one only:
[MOD_LDFLAGS="-module -avoid-version -export-dynamic -no-undefined -Wl,-E -Wl,--as-needed"]
that I think is the key one because it refers to LD flags.
But if I do this, the project seems to break an I receive messages saying the files used in the build have the wrong version of libtool.
make[4]: Entering directory '/cygdrive/d/gdrive/Thesis/tech/urv tech/graph-tool-2.2.31/src/graph/centrality'
CXX graph_betweenness.lo
libtool: Version mismatch error. This is libtool 2.4.2, but the
libtool: definition of this LT_INIT comes from libtool 2.4.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
libtool: and run autoconf again.
Makefile:507: recipe for target 'graph_betweenness.lo' failed
There are mentions also in aclocal.m4 that if I try to change cause additional problems related to build files version.
In addition, in ltmain.sh it is verified for some libraries if they have been generated with the flag export-dynamic.
So, several points here:
what is the difference between the .la and the .lo libraries that the module tries to generate?
I think the problem is related to differences in static and dynamic link but really don't know how to fix it. Are there other settings involved?
In general, any hints on what to try?

Related

How build pyobjc 7.3 with nix?

I want to build pyobjc-7.3, because it has fix for send2trash.
Classic building on BigSur 20.5.0 is strait forward.
cd pyobjc-7.3/pyobjc-framework-Cocoa
python3 setup.py build
though once I run same build inside nix-shell magic happens.
nix-shell -p pkgs.python39Packages.setuptools
python3 setup.py build
clang-7: error: argument unused during compilation:
'-fno-strict-overflow' [-Werror,-Wunused-command-lin\ e-argument]
ok. no big deal. let's disable warning.
CFLAGS="-Wno-unused-argument" python3 setup.py build
what? now clang is like a blind kitten.
Modules/pyobjc-api.h:19:10: fatal error: 'objc/objc.h' file not found
#include <objc/objc.h>
-isysroot option and -I has no effect.
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk
I noticed lots additions to -I flag in clang such as:
-iwithprefix /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include
it helps clang to find objc header file, though this is not the end of the story.
Modules/pyobjc-api.h:21:9: fatal error: 'Foundation/Foundation.h' file
not found
how come?!
oh there is another header files of special kind - frameworks. Wheel reinvention...
clang, take another argument
-iframeworkwithsysroot /System/Library/Frameworks
Here I get tons of type errors and I run out of ideas what could I try next:
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:138:1:
error:
function cannot return function type 'NSComparisonResult' (aka 'int (int)')
(NSComparisonResult)compare:(NSString *)string options:(NSStringCompareOptions)mask range:(NSR...
After days of trying I've found solution.
There are a few bugs are causing the problems:
First is nix provides older (10.12) sdk while setup.py thinks is 10.15.
This enables CPP sections for unsupported SDK API therefore type errors.
Following hack makes pyobjc to think that SDK is older that it is.
with pkgs;
with pkgs.lib;
with pkgs.python39Packages;
let
pyobjc-core = buildPythonPackage rec {
pname = "pyobjc-core";
version = "7.3";
name = "${pname}-${version}";
src = pkgs.python39Packages.fetchPypi {
pname = "pyobjc-core";
inherit version;
sha256 = "0x3msrzvcszlmladdpl64s48l52fwk4xlnnri8daq2mliggsx0ah";
};
preBuild=''
export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk"
Second problem is with header discovery and overstrict lint from python nix
CFLAGS = "-iwithsysroot /usr/include -Wno-unused-argument";
Third problem big sur linkder is dynamic and ffi libray is not found.
Providing through nix derivation
buildInputs = [ pkgs.libffi ];
Forth problem is tests are broken
doCheck = false;

CMake cannot find variable or directory

I tried to compile an old codebase. My environments are (as required by the codebase):
Python 2.7
CMake 2.8.10.1
The provided CMakeLists.txt looks like this:
cmake_minimum_required(VERSION 2.6)
project(KOL)
set (EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
#IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set (CMAKE_INSTALL_PREFIX ${CMAKE_SOURCE_DIR})
#ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
#check if Eigen exists
find_path(EIGEN_PATH NAMES Eigen PATHS ${EIGEN_DIR} REQUIRED)
if (NOT EIGEN_DIR)
message(FATAL_ERROR "Eigen is not found, please specify by: -DEIGEN_DIR=<eigen_path>")
endif (NOT EIGEN_DIR)
FILE(GLOB data_files src/data/*.h)
FILE(GLOB loss_files src/loss/*.h)
FILE(GLOB opti_files src/kernel/*.h)
FILE(GLOB comm_files src/common/*.h)
set (data_files ${data_files}
src/data/basic_io.cpp
)
include_directories(
${EIGEN_PATH}
)
#set (data_files ${datafiles}
# src/data/basic_io.cpp
# src/data/zlib_io.cpp
# src/data/gzip_io.cpp
# )
source_group("data" FILES ${data_files})
source_group("loss" FILES ${loss_files})
source_group("kernel" FILES ${opti_files})
source_group("common" FILES ${comm_files})
set (SRC_LIST
${data_files} ${loss_files} ${opti_files} ${comm_files}
)
IF(CMAKE_COMPILER_IS_GNUCXX)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-write-strings -O2 -s")
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
add_executable(KOL src/Params.cpp src/Params.h
src/main.cpp ${SRC_LIST})
IF(UNIX)
target_link_libraries(KOL pthread)
ENDIF(UNIX)
add_executable(Cacher src/data/Cacher.cpp ${data_files})
IF(UNIX)
target_link_libraries(Cacher pthread)
ENDIF(UNIX)
install(TARGETS KOL Cacher
DESTINATION .)
And my command is: cmake -EIGEN_DIR=../Eigen -CMAKE_CXX_FLAGS='-std=c++0x -O3' ..
The error is:
loading initial cache file MAKE_CXX_FLAGS=-std=c++0x -O3
CMake Error: Error processing file:MAKE_CXX_FLAGS=-std=c++0x -O3
-- The C compiler identification is Clang 10.0.1
-- The CXX compiler identification is Clang 10.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at CMakeLists.txt:13 (message):
Eigen is not found, please specify by: -DEIGEN_DIR=<eigen_path>
My project structure is like this:
--Master
|--build
|--Eigen
|--CMakeLists.txt
I ran the command inside of the build directory. It kept saying that EIGEN_PATH is not defined and Eigen is not found.
I tried -EIGEN_DIR=`pwd`/../Eigen. I also tried to use -DEIGEN_DIR but still got the same error. Please help.
You should use -DEIGEN_DIR from command line specifying the folder in Eigen library containing the FindEigen.cmake file (search for it with `find ../Eigen -name "*.CMake").
Be careful, the package name should match exactly (case sensitive):
the name of the find module or config script (FindPackageName.cmake or PackageNameConfig.cmake)
in find_package call
the name of the PackageName_DIR
To specify a cache variable via the CMake command line, use the -D flag before the variable names EIGEN_DIR and CMAKE_CXX_FLAGS. Here is the documentation for the cmake command line options and flags. Because this creates cached entries, try clearing your CMake cache before running the command, to get rid of any stale paths retained within.
Also, be sure to use double quotes " ... " when enclosing the flags for the CMAKE_CXX_FLAGS variable:
cmake -DEIGEN_DIR=Eigen -DCMAKE_CXX_FLAGS="-std=c++0x -O3" ..

Python / C++ binding, how to link agains static c++ library (portaudio) with distutils?

I am trying to staticaly link the "c++ portaudio library" against my "C++ demo module" which is a python callable library (module).
I'm doing this with distutils, and in order to perform the static linking, I've added the libportaudio to the extra_objects argument, as follows:
module1 = Extension(
"demo",
sources=cppc,
# TODO remove os dependency
extra_compile_args=gccArgs,
# link against shared libraries
#libraries=[""]
# link against static libraries
extra_objects=["./clib-3rd-portaudio/libportaudio.a"]) # << I've added the static lib here
Compiling with "python setup.py build" results in the following linker error:
/usr/bin/ld: ./clib-3rd-portaudio/libportaudio.a(pa_front.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
./clib-3rd-portaudio/libportaudio.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
So at this point I've tried the obvious, I've added the -fPIC flagg to gccArgs (note extra_compile_args=gccArgs above), as follows:
gccArgs = [
"-Icsrc",
"-Icsrc/paExamples",
"-Icinc-3rd-portaudio",
"-Icinc-3rd-portaudio/common",
"-Icinc-3rd-portaudio/linux",
"-fPIC"] # << I've added the -fPIC flag here
However this results in the exact same error, so I guess the -fPIC flag is not the root cause. I'm probably missing something trivial, but I'm a bit lost here, hope somebody can help.
As the error message said, you should recompile the external library libportaudio.a with -fPIC argument, NOT your own codes. That's why it doesn't help to add -fPIC to your extra_compile_args.
Several other posts suggest that the file libportaudio.a cannot be used to build shared library, probably because the default build settings of portaudio don't include -fPIC.
To recompile portaudio correctly, download the source and try to run ./configure with -shared option (or something similar). If you cannot find the proper option, then modify the Makefile and append -fPIC to the extra compile options. You can also compile each object file manually and pack them into libportaudio.a.
Since your target file (libdemo.so) is a shared library, you must make sure ANY object codes included inside are compiled with -fPIC option. To understand why you need this option, please refer to:
What does -fPIC mean when building a shared library? and Position Independent Code (PIC) in shared libraries

Installation forcing the use of python static archive rather than shared object

I've updated this question and the error it is giving me now, though I can't be certain whether I'm working towards or away from a solution, as I've little knowledge of cmake!
When trying to install a python program, I'm running into an error I'm uncertain how to fix. The program is as follows:
os.chdir("spenvis_csv")
if not os.path.exists("build"):
os.mkdir("build")
os.chdir("build")
call("cmake ../", shell=True)
call("make")
os.chdir(loc_dir)
os.chdir("python_utilities")
if not os.path.exists("lib"):
os.mkdir("lib")
for file_name in os.listdir("spenvis_csv/build/source"):
if file_name.find("libSpenvis.") !=-1:
shutil.move("spenvis_csv/build/source/%s" %
(file_name),"lib/Spenvis.so")
os.chdir("..")
And the error output is as follows:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/smh/Linux/Desktop/gras original/gras-03-03/python/python_utilities/spenvis_csv/build
Scanning dependencies of target Spenvis
[ 33%] Building CXX object source/CMakeFiles/Spenvis.dir/pySpenvisCSV.cc.o
[ 66%] Building CXX object source/CMakeFiles/Spenvis.dir/SpenvisCSV.cc.o
[100%] Building CXX object source/CMakeFiles/Spenvis.dir/SpenvisCSVCollection.cc.o
Linking CXX shared library libSpenvis.so
/usr/bin/ld: /usr/local/lib64/libpython2.7.a(abstract.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib64/libpython2.7.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [source/libSpenvis.so] Error 1
make[1]: *** [source/CMakeFiles/Spenvis.dir/all] Error 2
make: *** [all] Error 2
Ah, and I'm definitely a cmake scrub. In the source directory, methinks, lies the actual CMakeLists.txt, which is as follows:
# Make sure the compiler can find include files
include_directories (${PYSPENVIS_SOURCE_DIR})
# get boost
set(Boost_USE_STATIC_LIBS OFF)
#set(Boost_USE_MULTIEADED ON)
find_package(Boost COMPONENTS
python
REQUIRED)
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})
# get python
include(FindPythonLibs)
set(PythonLibs_USE_STATIC_LIBS OFF)
find_package(PythonInterp)
find_package(PythonLibs)
include_directories(${PYTHON_INCLUDE_DIRS})
link_directories(${PYTHON_LIBRARIES})
set_target_properties(${PYTHON_LIBRARIES} PROPERTIES POSITION_INDEPENDENT_CODE ON)
add_library(Spenvis SHARED pySpenvisCSV.cc SpenvisCSV.cc SpenvisCSVCollection.cc)
TARGET_LINK_LIBRARIES(Spenvis ${Boost_LIBRARIES} ${PYTHON_LIBRARIES})
With special attention to those last few lines, as those were the lines I've edited to point towards the correct libraries. However, now I'm getting a new error:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/smh/Linux/Desktop/gras-03-03/python/python_utilities/spenvis_csv/build
make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_python-mt.so.5', needed by `source/libSpenvis.so'. Stop.
make[1]: *** [source/CMakeFiles/Spenvis.dir/all] Error 2
make:
Particularly strange now is the /usr/lib64/lib64/ , I'm not sure why it's trying to find that directory, as it doesn't exist.
I apologize for the length. I've omitted the Internal cache entries, but can post these as well if they would be of use.

CMake not linking Python

Sorry if I'm duplicating a question, but I just cannot find the solution to what I'm looking for anywhere on the internet, yet I believe that this is a very simple problem.
I'm trying to extend python with some custom C++ libraries, and building my C++ libraries with CMake. I'm following the instructions on https://docs.python.org/2/extending/extending.html, but it's not compiling correctly.
When I try to build it, I get these messages:
"C:\Program Files (x86)\JetBrains\CLion 140.2310.6\bin\cmake\bin\cmake.exe" --build C:\Users\pkim2\.clion10\system\cmake\generated\76c451cd\76c451cd\Debug --target parsers -- -j 8
Linking CXX executable parsers.exe
CMakeFiles\parsers.dir/objects.a(main.cpp.obj): In function `spam_system':
C:/code/ground-trac/ground/launch/trunk/Software Support/Data Analysis Scripts/data_review_automation/parsers/main.cpp:9: undefined reference to `_imp__PyArg_ParseTuple'
C:/code/ground-trac/ground/launch/trunk/Software Support/Data Analysis Scripts/data_review_automation/parsers/main.cpp:12: undefined reference to `_imp__Py_BuildValue'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../libmingw32.a(main.o):(.text.startup+0xa7): undefined reference to `WinMain#16'
collect2.exe: error: ld returned 1 exit status
CMakeFiles\parsers.dir\build.make:87: recipe for target 'parsers.exe' failed
CMakeFiles\Makefile2:59: recipe for target 'CMakeFiles/parsers.dir/all' failed
CMakeFiles\Makefile2:71: recipe for target 'CMakeFiles/parsers.dir/rule' failed
mingw32-make.exe[3]: *** [parsers.exe] Error 1
mingw32-make.exe[2]: *** [CMakeFiles/parsers.dir/all] Error 2
mingw32-make.exe[1]: *** [CMakeFiles/parsers.dir/rule] Error 2
mingw32-make.exe: *** [parsers] Error 2
Makefile:109: recipe for target 'parsers' failed
Based on this, I suspect that this is a problem with the way I'm linking things in the CMakeLists.txt file, but I have no idea how to do it properly. This is what my CMakeLists.txt looks like right now:
cmake_minimum_required(VERSION 2.8.4)
project(parsers)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES main.cpp)
include_directories(C:\\Python27\\include)
link_directories(C:\\Python27\\)
target_link_libraries(python2.7)
add_executable(parsers ${SOURCE_FILES})
How in the world do I get this thing to compile correctly? I am running Windows 7 64-bit, and using CLion as my IDE.
Your first problem is that you are using target_link_libraries wrong: you should pass it the target to which to add a link and then the library you want to link in:
target_link_libraries(parsers python2.7)
Your second problem is that you are building an executable, instead of a shared library. If you want to make your extension accessible from python it needs to be a library.
add_library(parsers SHARED ${SOURCE_FILES})
But now comes the good news: your life becomes much simpler (and more portable) if you use the built in CMake module FindPythonLibs.cmake. To build a python module you would only need to do the following:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
find_package(PythonLibs REQUIRED)
add_library(parsers SHARED ${SOURCE_FILES})
include_directories(${PYTHON_INCLUDE_DIRS})
target_link_libraries(parsers ${PYTHON_LIBRARIES})
if you use windows, try this CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(CSample)
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -g -ftest-coverage -fprofile-arcs" )
link_directories(D:/Programs/mingw/mingw64/lib/)
include_directories(D:/Programs/Python/Python37/include/)
link_libraries(D:/Programs/Python/Python37/libs/python37.lib)
# Python
add_executable(CSample main.cpp)
You are using target_link_libraries() wrong. Check the docs; you probably want something like:
add_executable(parsers ${SOURCE_FILES})
target_link_libraries(parsers python2.7)
Note that the output from CMake should already tell you that something is wrong. On my machine:
CMake Error at CMakeLists.txt:8 (target_link_libraries):
Cannot specify link libraries for target "python2.7" which is not built by
this project.

Categories