[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #11 from Balint Reczey --- (In reply to Manuel López-Ibáñez from comment #10) > (In reply to Andrew Pinski from comment #5) > > (In reply to Manuel López-Ibáñez from comment #3) > > > Or at least give a clearer error that mentions -fPIC ... > > > > Actually this is not a driver issue just a binutils issue if that. Why add > > no-pie anyways to the ldflags. > > GCC controls the driver and decides what to pass to the linker. > > (In reply to Andrew Pinski from comment #8) > > Basically -no-pie says you are now doing an executable overriding the > > previous -shared. This is not a bug, you want -no-pie -shared. > > This seems counter-intuitive to how other options work. The documentation > says nothing about it. Then we wonder why people complain that GCC is harder > to use/learn. This is both counter-intuitive and inconvenient but I have to move on. I take this a WONTFIX and continue paving the way for using --enable-default-pie in Debian in a less pleasant way. Thank you at least for the quick response.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #10 from Manuel López-Ibáñez --- (In reply to Andrew Pinski from comment #5) > (In reply to Manuel López-Ibáñez from comment #3) > > Or at least give a clearer error that mentions -fPIC ... > > Actually this is not a driver issue just a binutils issue if that. Why add > no-pie anyways to the ldflags. GCC controls the driver and decides what to pass to the linker. (In reply to Andrew Pinski from comment #8) > Basically -no-pie says you are now doing an executable overriding the > previous -shared. This is not a bug, you want -no-pie -shared. This seems counter-intuitive to how other options work. The documentation says nothing about it. Then we wonder why people complain that GCC is harder to use/learn.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #9 from Andrew Pinski --- -no-pie Don't produce a position independent executable. Maybe the wording is a bit weird but -no-pie says produce an executable which is not position independent executable.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #8 from Andrew Pinski --- Basically -no-pie says you are now doing an executable overriding the previous -shared. This is not a bug, you want -no-pie -shared. So if you want to disable pie for some building just set CC (and CXX and LD) to be "gcc -no-pie" and that will work the way you think it will work. It won't override if the application understands it wants pie but it also allows shared libraries to work correctly.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #7 from Balint Reczey --- (In reply to Andrew Pinski from comment #1) > You need -fPIC to create shared libraries. I know that the relevant options are -fPIC and -fno-PIC. I have opened the bug to handle -shared -no-pie and -no-pie -shared consistently and equivalently to -shared only.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #6 from Balint Reczey --- (In reply to Andrew Pinski from comment #5) > (In reply to Manuel López-Ibáñez from comment #3) > > Or at least give a clearer error that mentions -fPIC ... > > Actually this is not a driver issue just a binutils issue if that. Why add > no-pie anyways to the ldflags. I would like to enable --enable-default-pie in gcc but I would like to default to not using PIE in the top-level Makefile/configure of some projects. If "gcc -shared -no-pie foo.c" does not have the same result as "gcc -shared foo.c" this becomes practically impossible and one need to disable PIE for each binary one-by-one patching the build system. Also please note that reversing the parameters works and generates a shared library as expected: # gcc -no-pie -shared foo.c # file a.out a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=6512dec4e91253fccda6977a39099c0d4d304629, not stripped One of those must be a valid bug. For practical reasons please consider the first reported issue as valid. From gcc's man page: -no-pie Don't produce a position independent executable. IMO -shared does not produce an executable, thus -no-pie should be silently handled as a noop without an error.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #5 from Andrew Pinski --- (In reply to Manuel López-Ibáñez from comment #3) > Or at least give a clearer error that mentions -fPIC ... Actually this is not a driver issue just a binutils issue if that. Why add no-pie anyways to the ldflags.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No. In most cases the -shared and the compiling part are separated. This was just a simplified example of not using the right options.
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 --- Comment #3 from Manuel López-Ibáñez --- Or at least give a clearer error that mentions -fPIC ...
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 Manuel López-Ibáñez changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||manu at gcc dot gnu.org Resolution|INVALID |--- --- Comment #2 from Manuel López-Ibáñez --- (In reply to Andrew Pinski from comment #1) > You need -fPIC to create shared libraries. Couldn't the driver do this on its own internally?
[Bug c/77464] gcc -no-pie breaks -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You need -fPIC to create shared libraries.
