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.