Fix build and linking issue on 64-bit

[KapiX]

Comments about -pie flag:
I'm guessing WebKit/WebKit@8b224d4 broke linking when it switched to CMAKE_POSITION_INDEPENDENT_CODE.
Haiku's CMake platform file does not have PIC/PIE flags defined (removed here Kitware/CMake@7ebc1cb#diff-6a683ecc2f7a61f1096c7918bfd12a70) although they are correctly added during build when compiling source files. It's linking that fails and -pie is a linker flag.
Also CMake's test for Position Independent Executables passes.
The only platform that has it defined is Android:
https://github.com/Kitware/CMake/search?utf8=%E2%9C%93&q=-pie&type=

Build tested with 64-bit GCC 7.3. Please test if it builds on 32-bit.

[pulkomandy]

github search seems unreliable on big repos, for me it does not see anything in Android, but finds something for SunOS.

So I guess we have a problem with our CMake port (the WebKit commit message does mention "cmake adds the flag for us").

[KapiX]

For me it shows three results, and android one is second:
https://github.com/Kitware/CMake/blob/4e23a1d0eb0eca303d28c3f5b7b7147739f891b3/Modules/Platform/Android/abi-common.cmake#L16

Anyway, why do we need -pie for linker in the first place? As I mentioned, -fPIC and -fPIE flags are added correctly for source files, and PIE unit test in CMake's test suite passes.

[pulkomandy]

Ok, so let's dig into cmake.

According to the docs, what CMAKE_POSITION_INDEPENDENT_CODE does is set the default value for POSITION_INDEPENDENT_CODE, which can also be set per-target. So the Android handling seems suspicious.

If we dig into POSITION_INDEPENDENT_CODE, we can see it is implemented here: https://github.com/Kitware/CMake/blob/d4b97e8d721e5a5374a400bcdd5df1eb4e1cf7d2/Source/cmLocalGenerator.cxx#L1783 by adding the "position independant flags". This (https://github.com/Kitware/CMake/blob/d4b97e8d721e5a5374a400bcdd5df1eb4e1cf7d2/Source/cmLocalGenerator.cxx#L1832) in turn looks for CMAKE_CXX_COMPILE_OPTIONS_PIE and _PIC. Clearly the Haiku platform file forgets to set these: https://github.com/Kitware/CMake/search?p=1&q=CMAKE_C_COMPILE_OPTIONS_PIE&type=&utf8=✓ (possibly they are not needed on x86 and/or gcc2 in our case beause of tweaks in our gcc port).

[KapiX]

I'd still go with our GCC being broken. Compare:
https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/gcc/config/i386/gnu-user64.h#L67
with
https://github.com/haikuports/haikuports/blob/master/sys-devel/gcc/patches/gcc-5.4.0_2016_06_04.patchset#L838
and
https://github.com/haikuports/haikuports/blob/master/sys-devel/gcc/patches/gcc-7.3.0_2018_05_01.patchset#L906

EDIT: admittedly, -pie is not in 7.3.0, and it is for static-pie target, but I think this flag is supposed to be passed implicitily, and fixing this in CMake is just a workaround.

[pulkomandy]

-fPIC is enabled by default for our GCC (if I'm not mistaken, it happens by redefining CC1_SPEC). We do this because our executables are always shared objects, and can be loaded as add-ons into other executables (at least for 32bit systems, maybe we do something different for 64bit). This can explain the difference on gcc side (but it's quite possible something isn't done right there too).

[KapiX]

Yes, and if I understand correctly there is equivalent LINK_SPEC which I think should contain -pie, but currently it doesn't.

[nielx]

I've changed this line of the LINK_SPEC from elf_x86_64_haiku to elf_x86_64, and this did not make a difference when compiling a 32-bit cross-compiler from 64 bit Haiku. I'm wondering if that's actually the change you were referring to...