|
In addition to building an executable binary of my application, I also use SWIG to wrap my program to be called from Python.
SWIG sets up a shared object library that gets loaded by Python. This has to be a shared object because the alternative would be a custom built version of Python with my program (and FLTK) statically linked into it. No good can come from that.
I have two versions of this wrapper -- one without graphics and one with the full GUI and OpenGL graphics embedded. We can launch our program's full GUI from within Python -- but that isn't the point of the story.
When we create this shared object, we try to statically link everything we can -- including FLTK. So, we're statically linking FLTK into a shared library.
This has generally worked on Windows, MacOS, and Linux for a while. For Linux, I've worked with Ubuntu 18 and 20 and RHEL7. I recently started working with RHEL9.
For some reason, on RHEL9, when I go to link the Python wrapper with FLTK into the shared object, I get the following error:
/usr/bin/ld: crt1.0: in function `_start': (.text+0x1b): undefined reference to `main’
collect2: error: ld returned 1 exit status
Of course, since this is a shared object, I don't have a main().
I dug into the details of the linker command and eventually discovered that it included a '-no-pie' that if removed, linking would proceed as desired.
After considerable digging, I figured out that the '-no-pie' is coming from fltk:fltk. I used this utility (discussed previously here) to peer into everything in this target. The output is below:
fltk::fltk BINARY_DIR = /home/somepath/build/gccrel-VSP/src
fltk::fltk IMPORTED = TRUE
fltk::fltk IMPORTED_CONFIGURATIONS = RELEASE
fltk::fltk INTERFACE_INCLUDE_DIRECTORIES = /home/somepath/build/gccrel-Libs/FLTK-prefix/include
fltk::fltk INTERFACE_LINK_DIRECTORIES = /home/somepath/build/gccrel-Libs/FLTK-prefix/lib
fltk::fltk INTERFACE_LINK_LIBRARIES = /usr/lib64/libdl.a;/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libXinerama.so;/usr/lib64/libXfixes.so;/usr/lib64/libXcursor.so;/usr/lib64/libXrender.so;/usr/lib64/libpango-1.0.so;/usr/lib64/libpangocairo-1.0.so;/usr/lib64/libcairo.so;/usr/lib64/libgobject-2.0.so;/usr/lib64/libpangoxft-1.0.so;/usr/lib64/libXft.so;/usr/lib64/libfontconfig.so;-lwayland-egl -lEGL;-L/usr/lib64;-lgtk-3;-lgdk-3;-lpangocairo-1.0;-lpango-1.0;-lharfbuzz;-latk-1.0;-lcairo-gobject;-lcairo;-lgdk_pixbuf-2.0;-lgio-2.0;-lgobject-2.0;-lglib-2.0;-lwayland-cursor -lwayland-client -lxkbcommon -ldl;-L/usr/lib64;-ldbus-1;-no-pie
fltk::fltk LOCATION = /home/somepath/build/gccrel-Libs/FLTK-prefix/lib64/libfltk.a
fltk::fltk LOCATION_Release = /home/somepath/build/gccrel-Libs/FLTK-prefix/lib64/libfltk.a
fltk::fltk MACOSX_PACKAGE_LOCATION = /home/somepath/build/gccrel-Libs/FLTK-prefix/lib64/libfltk.a
fltk::fltk NAME = fltk::fltk
fltk::fltk SOURCE_DIR = /home/somepath/repo/src
fltk::fltk SYSTEM = ON
fltk::fltk TYPE = STATIC_LIBRARY
fltk::fltk VS_DEPLOYMENT_LOCATION = /home/somepath/build/gccrel-Libs/FLTK-prefix/lib64/libfltk.a
Notice that INTERFACE_LINK_LIBRARIES contains -no-pie. Notably, this is a linker option, not a library.
The FLTKConfig.cmake.in file contains no reference to -no-pie. So I dug into the FLTK source, and there are three hits. One in ./configure.ac, one in libdecor, and the relevant one in /src/CMakeLists.txt:768.
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux" AND NOT FLTK_BUILD_SHARED_LIBS)
list(APPEND OPTIONAL_LIBS "-no-pie")
endif(CMAKE_HOST_SYSTEM_NAME STREQUAL "Linux" AND NOT FLTK_BUILD_SHARED_LIBS)
This is perhaps a reasonable thing to do if you assume that fltk is going to be statically linked into an executable program. It does not work in my situation where fltk is statically linked into a shared library.
I am also not certain how appropriate it is that this 'leaks' its way into the fltk:fltk target. Perhaps it must be this way. I don't fully understand all the mechanisms at work.
At a minimum, I'm pretty sure this should be assigned to a target LINK_OPTIONS property. Or, perhaps even better, a target POSITION_INDEPENDENT_CODE property (rather than appended to a string list of library names).
I don't know the long-term fix for this.
In the short term, I'm going to attempt something like
get_target_property(templist fltk:fltk INTERFACE_LINK_LIBRARIES)
list(REMOVE_ITEM templist "-no-pie")
set_target_properties(fltk:fltk PROPERTIES INTERFACE_LINK_LIBRARIES ${templist})
Or something like that.
Rob
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/57e72556-e9cd-4787-8026-f19bd5bc1fbfn%40googlegroups.com.
[ Direct Link to Message ] | 
