https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262
Bug ID: 88262
Summary: gcc uses crt1.o in place of Scrt1.o when the main
function is in a PIC shared lib
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: stephen.kim at oracle dot com
Target Milestone: ---
I am not yet certain that this is a gcc bug or user's fault. That's why I am
filing a bug here to get other engineers' thoughts.
I have a non-PIC app.o, which does not have the main function but a set of
functions, variables, etc. Besides, I have a PIC shared library, say,
libmain.so, which has the main function.
Having a "PIE" is not mandatory, so I just linked the two like this:
gcc -o app.x -L. -lmain -fuse-ld=gold -Wl,-rpath=$PWD app.o
Running app.x gives me a segmentation fault when the glibc is sufficiently
new--the patch that triggers this issue is created this year--and the platform
is arm64.
The reason is when gcc invokes gold, gcc gives it crt1.o rather than Scrt1.o.
Multiple experts confirmed that Scrt1.o should be given in this case.
I am wondering if this is a gcc bug that should be fixed in the gcc driver. Or,
would it be claimed that the users (e.g. myself) should have used "-pie" to
link them although making a PIE is not mandatory from my perspective?
Regarding severity, as a C and C++ programmer, I personally have not placed
main inside a shared library. I haven't yet faced at work any pure C/C++ code
that has the main inside a PIC shared library. This might not be highly common
in the C and C++ worlds.
However, Go tools always do this with a certain combination of buildmode. I
would expect this situation happens more there.
