Tracking down -no-pie

I am building a SWIG wrapped Python module (shared library). I build two versions – one without any graphics, another with a GUI that requires linking various graphics and OpenGL libraries.

This generally works fine across Windows, MacOS, and Linux, using MSVC, CLang, and GCC. I’ve built everything on multiple versions of Ubuntu with GCC and multiple versions of RHEL/CENTOS with GCC.

For some reason, when I build the graphics enabled version of the shared object on RHEL9, I get a linker error like (the non-graphics one works fine)…

/usr/bin/ld: crt1.0: in function _start': (.text+0x1b): undefined reference to main’
collect2: error: ld returned 1 exit status

Of course, there shouldn’t be a main() because I’m not building an executable, I’m building a *.so module to be loaded into Python.

I managed to dump out the full command line for the linker. By trial and error, I was able to determine that the command line had a ‘-no-pie’ – if removed, it created the *.so without issue.

The linker command also contains ‘-fPIC -shared’.

It seems that one of the graphics libraries is somehow adding ‘-no-pie’ to the linker options.

How can I diagnose how this is set? Is it possible to print the list of linker options for a target? What are all the CMake variables used to assemble a linker command – there must be a *.o file, an output file name, library search directories, libraries to link against, linker options, etc… how can I peel back the onion to see where / how each of these is set (and what it contains)?

Can linker options be carried along with a library?

And of course, if I can’t figure out how to prevent this flag from being set, how can I remove a linker option from a target?

Thanks for any help.

I’ve done a bit more digging. I used [this utility](How to print all the properties of a target in cmake? - Stack Overflow +) to print out all properties associated with my targets. I redirected to a file and compared my graphics vs. no-graphics target output.

There is no smoking gun…

Candidate properties like:


Are all set identically. All properties that are set differently are the ones that obviously should be set differently.

Do we know what logic CMake uses to set the -no-pie flag?

OK, I was able to pin it down to FLTK. I’m asking on their mailing list.

As a workaround, I’m going to try something like this…

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})