[Ohrrpgce] Can't compile 64-bit hspeak on the nightly build vm

James Paige Bob at hamsterrepublic.com
Sun Dec 24 17:25:54 PST 2017 

Ouch! *bumps into something wooden at knee level*

james at breq:~/src/ohrrpgce$ scons test
scons: Reading SConscript files ...
Using target: linux  arch: x86_64  gcc: gcc  cc: gcc  gcctarget:
x86_64-linux-gnu  gccversion: 540  fbcversion: 1050
scons: done reading SConscript files.
scons: Building targets ...
fbc -c reloadtest.bas -o build/reloadtest.o -m reloadtest -mt -g -exx -O 2
-target linux -arch x86_64 -gen gcc -Wc
-nopie,-Wno-maybe-uninitialized,-Wno-array-bounds,-fno-omit-frame-pointer
gcc -o build/os_unix.o -c -Wall -g -O3 -DFBCVERSION=1050 -nopie -m64
--std=gnu99 os_unix.c
gcc: error: unrecognized command line option '-nopie'
fbc -c os_unix2.bas -o build/os_unix2.o -mt -g -exx -O 2 -target linux
-arch x86_64 -gen gcc -Wc
-nopie,-Wno-maybe-uninitialized,-Wno-array-bounds,-fno-omit-frame-pointer
fbc -c util.bas -o build/util.o -mt -g -exx -O 2 -target linux -arch x86_64
-gen gcc -Wc
-nopie,-Wno-maybe-uninitialized,-Wno-array-bounds,-fno-omit-frame-pointer
scons: *** [build/os_unix.o] Error 1
gcc: error: unrecognized command line option '-nopie'
scons: *** [build/os_unix2.o] Error 1
gcc: error: unrecognized command line option '-nopie'
scons: *** [build/reloadtest.o] Error 1
gcc: error: unrecognized command line option '-nopie'
scons: *** [build/util.o] Error 1
scons: building terminated because of errors.
james at breq:~/src/ohrrpgce$



On Sun, Dec 24, 2017 at 6:45 AM, James Paige <Bob at hamsterrepublic.com>
wrote:

>
>
> On Sunday, December 24, 2017, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>> Hmm, this is quite a mess. I hadn't noticed the -no_pie spelling in
>> SConscript. Also some of these are gcc flags and some are linker flags. I
>> guess this explains a comment I saw that gcc "standardised on -no-pie".
>>
>> PIE is only needed on android when building executables, not .so files.
>> So, it's only for compiling commandline tests and utilities, not Game
>> (which is compiled to libapplication.so)
>>
>> I feel like keeping builds working on dozens of different platforms and
>> configurations and compiler versions is like stumbling around in a dark
>> room, and every time you stub your toe on a piece of furniture you try to
>> move it out of the way, so never learn where the furniture is!
>>
>>
> That is an apt metaphor!
>
>
>>
>> On 24 December 2017 at 19:00, James Paige <Bob at hamsterrepublic.com>
>> wrote:
>>
>>> Looking around the SConscript file, I can see that all three of -nopie
>>> -no_pie -no-pie seems to exist in one place or another.
>>>
>>> I also see a comment saying that PIE is mandatory for Android builds.
>>>
>>> On Sat, Dec 23, 2017 at 9:41 PM, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>> Oh sorry, I got distracted before fixing this.
>>>> The way to see whether PIE is the default is apparently to inspect "gcc
>>>> -dumpspecs".
>>>> The easiest solution is probably to always do a non-PIE build
>>>> (otherwise, we have to link the correct FB libraries).
>>>> -no-pie is definitely new in GCC 6. What's not clear is whether old
>>>> versions always had -nopie. It apparently wasn't documented, at least.
>>>>
>>>> On 24 December 2017 at 10:45, James Paige <Bob at hamsterrepublic.com>
>>>> wrote:
>>>>
>>>>> So would it be reasonable to have scons run "g++ -no-pie" and parse
>>>>> the output to determine whether or not the option is supported?
>>>>>
>>>>> On a system where it is supported:
>>>>>
>>>>> james at breq:~$ g++ -no-pie
>>>>> g++: fatal error: no input files
>>>>> compilation terminated.
>>>>>
>>>>> On a system where is is not supported:
>>>>>
>>>>> james at ixrat:~$ g++ -no-pie
>>>>> g++: error: unrecognized command line option ‘-no-pie’
>>>>> g++: fatal error: no input files
>>>>> compilation terminated.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 20, 2017 at 8:41 AM, James Paige <Bob at hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>> Yes, I can confirm that adding "-no-pie" in CXXLINKFLAGS does indeed
>>>>>> work. I can just type plain "scons" and it compiles correctly.
>>>>>>
>>>>>> On Wed, Dec 20, 2017 at 2:35 AM, Ralph Versteegen <teeemcee at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Bah. I wasn't expecting that to work. fbc apparently only does a PIC
>>>>>>> build when building a dynamic library, not when building an executable. I
>>>>>>> think what's going on here is that fbc calls ld directly, while linkgcc=1
>>>>>>> uses gcc to indirectly call the linker. I guess it's gcc itself which is
>>>>>>> telling ld to do a PIE build. I want to fix linkgcc=1.
>>>>>>>
>>>>>>> So could you please try editing SConscript to replace
>>>>>>> CXXLINKFLAGS = []
>>>>>>> with
>>>>>>> CXXLINKFLAGS = ["-no-pie"]
>>>>>>> and see if that works (running just plain "scons")
>>>>>>>
>>>>>>> On 20 December 2017 at 16:23, James Paige <Bob at hamsterrepublic.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ah, yes! scons linkgcc=0 did the trick. :)
>>>>>>>>
>>>>>>>> On Tue, Dec 19, 2017 at 1:10 AM, Ralph Versteegen <
>>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hmm. Most of the errors are in libfbmt.a. But a couple of the
>>>>>>>>> relocation errors are in .bas modules,  "relocation R_X86_64_32
>>>>>>>>> against `.rodata.str1.1' " and I don't understand why - if gcc is
>>>>>>>>> defaulting to PIC,
>>>>>>>>> As fir why gcc says "...can not be used when making a shared
>>>>>>>>> object", I'm guessing that's a gcc bug, since PIC is normally
>>>>>>>>> only required when creating a dynamic library on non-x86, so configuring
>>>>>>>>> gcc to force it also for executables might activate the same codepath.
>>>>>>>>>
>>>>>>>>> Anyway, see if any of the following work:
>>>>>>>>> scons linkgcc=0
>>>>>>>>> FBFLAGS=-pic scons linkgcc=0
>>>>>>>>> FBFLAGS="-Wl -no-pie" scons
>>>>>>>>> (I suggest linkgcc=0 because linkgcc=1 always links libfbmt.a,
>>>>>>>>> never libfbmtpic.a which is compiled with -fPIC)
>>>>>>>>>
>>>>>>>>> On 19 December 2017 at 16:47, James Paige <Bob at hamsterrepublic.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I should have mentioned I already tried scons -c and it didn't
>>>>>>>>>> help :(
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday, December 18, 2017, Ralph Versteegen <
>>>>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Run "scons -c" to delete the old object files. Since they were
>>>>>>>>>>> compiled without -fPIC, which is now the default in debian 9, they can't be
>>>>>>>>>>> linked into a PIE executable.
>>>>>>>>>>>
>>>>>>>>>>> On 19 December 2017 at 14:05, James Paige <
>>>>>>>>>>> Bob at hamsterrepublic.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So I made a copy of the 64 bit Linux VM, and upgraded it from
>>>>>>>>>>>> Debian 8 to Debian 9.
>>>>>>>>>>>>
>>>>>>>>>>>> hspeak compiles fine now as a 64 bit binary, but I can no
>>>>>>>>>>>> longer compile ohrrpgce-game and ohrrpgce-custom
>>>>>>>>>>>>
>>>>>>>>>>>> when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(io_print_wstr.o): relocation R_X86_64_32 against undefined symbol `__fb_ctx' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(io_printvoid_wstr.o): relocation R_X86_64_32 against `.rodata.str4.4' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(sys_getexename.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(file_print_wstr.o): relocation R_X86_64_32 against undefined symbol `__fb_ctx' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(io_printpad_wstr.o): relocation R_X86_64_32 against `.rodata.str4.4' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(dev_scrn_write_wstr.o): relocation R_X86_64_32S against symbol `fb_DevScrnWriteWstr' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(io_printbuff_wstr.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: /usr/local/bin/../lib/freebasic/linux-x86_64/libfbmt.a(array_erase.o): relocation R_X86_64_PC32 against symbol `free@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
>>>>>>>>>>>> /usr/bin/ld: final link failed: Bad value
>>>>>>>>>>>> collect2: error: ld returned 1 exit status
>>>>>>>>>>>> scons: *** [ohrrpgce-game] Error 1
>>>>>>>>>>>> scons: building terminated because of errors.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Dec 17, 2017 at 10:21 AM, James Paige <
>>>>>>>>>>>> Bob at hamsterrepublic.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Today I will try upgrading Debian on a copy of the 64-bit VM,
>>>>>>>>>>>>>  Hopefully that will resolve it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> James
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Dec 16, 2017 at 4:00 PM, Ralph Versteegen <
>>>>>>>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -no-pie is actually passed by SConscript.  I can't find any
>>>>>>>>>>>>>> mention in my emails about a -no-pie problem on debian. The problem we had
>>>>>>>>>>>>>> was that -no-pie was supported (nor necessary) for clang on OSX.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The -no-pie flag was added in r9542:
>>>>>>>>>>>>>> """
>>>>>>>>>>>>>> scons: Fix hspeak builds on Arch Linux and others where gcc
>>>>>>>>>>>>>> defaults to PIE
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Euphoria 4.1 builds we recommend (and which are also used
>>>>>>>>>>>>>> by the Arch
>>>>>>>>>>>>>> opeeuphoria package on AUR) haven't been built for PIE
>>>>>>>>>>>>>> """
>>>>>>>>>>>>>> Apparently this flag is also necessary on (recent?) Debian
>>>>>>>>>>>>>> and Ubuntu, as they also default to PIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's not clear, but from searching around it appears that
>>>>>>>>>>>>>> this flag used to be called -nopie until gcc 6 switched to -no-pie. So try
>>>>>>>>>>>>>> that. I have the man page for gcc 4.8 here, and it doesn't say either way.
>>>>>>>>>>>>>> Also, there is -fno-pie which is a compiler flag while
>>>>>>>>>>>>>> -no-pie is a linker flag (also understood by gcc). So you could also try
>>>>>>>>>>>>>> that and see whether it works. (I assume that -no-pie passed to gcc implies
>>>>>>>>>>>>>> -fno-pie)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16 December 2017 at 12:3
>>>>>>>>>>>>>> 2, James Paige <Bob at hamsterrepublic.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So now I remember why I have the 32-bit version of Euphoria
>>>>>>>>>>>>>>> installed on the Linux nightly build machine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The hspeak build fails because gcc doesn't understand
>>>>>>>>>>>>>>> --no-pie
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gcc -o /home/james/src/ohr/wip/hspeak init-.o hspeak.o
>>>>>>>>>>>>>>> main-.o hspeak_0.o hspeak_1.o hspeak_2.o hspeak_3.o hspeak_4.o hsspiffy.o
>>>>>>>>>>>>>>> file.o sort.o get.o graphics.o machine.o math.o types.o unicode.o
>>>>>>>>>>>>>>> ucstypes.o io_with_unicode.o 0achine.o memory.o dll.o
>>>>>>>>>>>>>>> /usr/share/euphoria/bin/eu.a -m64 -ldl -lm -lpthread -no-pie
>>>>>>>>>>>>>>> gcc: error: unrecognized command line option '-no-pie'
>>>>>>>>>>>>>>> hspeak.mak:97: recipe for target
>>>>>>>>>>>>>>> '/home/james/src/ohr/wip/hspeak' failed
>>>>>>>>>>>>>>> make: *** [/home/james/src/ohr/wip/hspeak] Error 1
>>>>>>>>>>>>>>> make: Leaving directory '/home/james/src/ohr/wip/build
>>>>>>>>>>>>>>> /hspeak'
>>>>>>>>>>>>>>> scons: done building targets.
>>>>>>>>>>>>>>> james at ixrat:~/src/ohr/wip$ euc -v
>>>>>>>>>>>>>>> Euphoria to C Translator v4.1.0 development
>>>>>>>>>>>>>>>    64-bit Linux, Using System Memory
>>>>>>>>>>>>>>>    Revision Date: 2015-02-02 14:18:53, Id: 5861:57179171dbed
>>>>>>>>>>>>>>> james at ixrat:~/src/ohr/wip$ gcc --version
>>>>>>>>>>>>>>> gcc (Debian 4.9.2-10) 4.9.2
>>>>>>>>>>>>>>> Copyright (C) 2014 Free Software Foundation, Inc.
>>>>>>>>>>>>>>> This is free software; see the source for copying
>>>>>>>>>>>>>>> conditions.  There is NO
>>>>>>>>>>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A
>>>>>>>>>>>>>>> PARTICULAR PURPOSE.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am wondering if the easiest way to resolve this might be
>>>>>>>>>>>>>>> to upgrade the virtual machine from Debian 8.x to 9.x and hopefully get a
>>>>>>>>>>>>>>> version of gcc that does not have this problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For now, I am leaving the 64-bit version of euphoria
>>>>>>>>>>>>>>> installed on the vm, so the 64-bit nightly builds are going to remain
>>>>>>>>>>>>>>> broken until I have figured out a solution.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> James
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>>>>>>>> amster.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>>>>>>> amster.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>>>>> amster.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>>> amster.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>> amster.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ohrrpgce mailing list
>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>> amster.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>> amster.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20171224/56d42d61/attachment-0001.html>

More information about the Ohrrpgce mailing list