Fix linking on Debian Stretch (gcc-6)

[kent-mcleod]

This continues on top of #100 which was closed.

I've had this sitting around for a while. Not sure if it is appropriate for merging.

This should fix: #85, #99, #102 and #113 (Or at least advance)

Tagging @liuw because I'm reusing one of your commits and unsure you will get notified.

[anttikantee]

Would passing no-pie via [ACL]*FLAGS to buildrump.sh work? That's how other permanent toolchain flags are set.

[kent-mcleod]

Using ACLFLAGS doesn't work because it appears to pass the flag directly to the underlying cc1 which causes the error:
cc1: error: command line option ‘-no-pie’ is valid for the driver but not for C
This occurs when I try and use a rumprun toolchain (eg x86_64-rumprun-netbsd-gcc) after building with CXX=false ./build-rr.sh hw -- -F ACLFLAGS=-no-pie

[kent-mcleod]

Tracking it down further, it's because !CFLAGS! is used for *cc1_options: in specs-compile_or_ferment (which makes sense) but the cc1 command doesn't understand -no-pie. So even though -pie is a flag that both gcc and the underlying cc1 command understands, -no-pie is only understood by gcc but treated as invalid by cc1.

[anttikantee]

If it's a linker-only flag, use only LFLAGS.

[anttikantee]

or LDFLAGS. plus or minus some other obvious typos I make

[kent-mcleod]

Also doesn't work. Did more experiments.

• -pie and -r together cause the linker to die.
• gcc is generating the -pie because of --enable-default-pie
• Appending -no-pie to the linker command either by adding -no-pie to the *link: rule of the specs file, or by adding -Wl,-no-pie doesn't cancel out the -pie added by gcc. It results in something like -pie -r -no-pie and then /usr/bin/ld: -r and -pie may not be used together
• Passing -no-pie to gcc (without -Wl, before it) prevents gcc from adding the -pie flag.

So on gcc-6+ configured with --enable-default-pie it seems like there isn't a way to link relocatable unless -no-pie is given to gcc before the specs file or linker arguments are parsed.

[anttikantee]

It's then a good demonstration of why new ways to handle existing things can be bad for users ...

Anyway, we can't fix underlying lossage, just work around it. I'd test for the condition only once in build-rr, though. I don't think the toolchain wrappers are supposed to handle the underlying toolchain changing, so testing at runtime is not necessary.

[kent-mcleod]

So something like fbcc68f?

[anttikantee]

I'd put the result into config.{mk,sh} instead of using export so that if someone runs make in the tree manually, the consistent thing happens. And, I'd use a more generic name like EXTRACCFLAGS (or a better name ;), so that other similar options don't need to be patched in many places. But, I'm just nitpicking, and by large, yes.

Do you want push access to merge and maintain your patch?

[kent-mcleod]

Ok and Ok. I'll update and flatten my commits.

[kent-mcleod]

Ok I'm ready for this to be merged if it is sufficient.

[anttikantee]

If you're going to maintain it, I have no objections ;-)

thanks!

[kent-mcleod]

Sure, I can maintain it in the future.

[anttikantee]

thanks again