Oolite Bulletins
http://bb.aegidian.org/

Compiling on recent (2017) distros - GCC 6.x issues
http://bb.aegidian.org/viewtopic.php?f=9&t=18796
Page 2 of 2

Author:  zevans [ Wed May 17, 2017 5:45 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

I saw the latest commit included the "null" fixes so I started again with a fresh clone, just to make sure it does build now.

Success! Thanks for all your help.

I had to add -Ideps/mozilla/js/src/to the compile command as I suspected. Need to figure out why "make" isn't doing that automatically so we can put a long-term fix in the codebase.

Author:  Getafix [ Thu May 18, 2017 1:45 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

What if you do the following:
Code:
$ make -f Makefile distclean
$ make -f Makefile release-snapshot
Does it compile the whole thing?

Author:  zevans [ Fri May 19, 2017 3:52 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

Quote:
What if you do the following:
Code:
$ make -f Makefile distclean
$ make -f Makefile release-snapshot
Does it compile the whole thing?
Nope. Here is the minimum needed for the make command, and I've included an example error of what happens when the flags are omitted.
Code:
make -f Makefile release-snapshot \
OBJCFLAGS+="-Wno-format-security"  \
CXXFLAGS+="-Wno-narrowing" \
CXXFLAGS+="-DENABLE_ASSEMBLER"
Examples...
Code:
CFLAGS+="-Wno-narrowing"

../nanojit/NativeX64.cpp:1902:81: error: narrowing conversion of ‘9223372036854775808ull’ from ‘long long unsigned int’ to ‘int64_t {aka long int}’ inside { } [-Wnarrowing]
     static const AVMPLUS_ALIGN16(int64_t) negateMask[] = {0x8000000000000000LL,0};
In this next one it looks like something in the makefile (or configure) is changing this warning TO an error, and these buffer overruns are in the core code, not SpiderMonkey...
Code:
OBJCFLAGS+="-Wno-format-security"

Compiling file src/Core/Debug/OODebugMonitor.m ...
src/Core/Debug/OODebugMonitor.m: In function ‘-[OODebugMonitor dumpMemoryStatistics]’:
src/Core/Debug/OODebugMonitor.m:511:2: error: format not a string literal and no format arguments [-Werror=format-security]
  OOLog(@"debug.memStats", @"Memory statistics:");
  ^
cc1obj: some warnings being treated as errors
And the linking problem discussed earlier in this thread.
Code:
CXXFLAGS+="-DENABLE_ASSEMBLER"

c++ -o js -Wno-narrowing  js.o jsworkers.o   -lpthread   -Wl,-rpath-link,/bin -Wl,-rpath-link,/usr/local/lib  -L../dist/bin -L../dist/lib -L/usr/lib/x86_64-linux-gnu -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -ldl
../libjs_static.a(jsapi.o): In function `js::RegExp::compileHelper(JSContext*, JSLinearString&)':
jsapi.cpp:(.text._ZN2js6RegExp13compileHelperEP9JSContextR14JSLinearString[_ZN2js6RegExp13compileHelperEP9JSContextR14JSLinearString]+0x7d): undefined reference to `JSC::Yarr::jitCompileRegex(JSC::ExecutableAllocator&, JSC::Yarr::RegexCodeBlock&, JSLinearString const&, unsigned int&, int&, bool&, bool, bool)'
/usr/bin/ld: js: hidden symbol `_ZN3JSC4Yarr15jitCompileRegexERNS_19ExecutableAllocatorERNS0_14RegexCodeBlockERK14JSLinearStringRjRiRbbb' isn't defined
/usr/bin/ld: final link failed: Bad value

Author:  another_commander [ Fri May 19, 2017 4:35 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

The format security error should be fixed in trunk; please check. There seems to be something odd with your build setup, because ENABLE_ASSEMBLER (as well as a few other macros needed for Spidermonkey JIT) should be already defined - at least they seem to be in the dev evnironments that build the Linux packages and maybe Getafix can help here by confirming or denying this.

Author:  Getafix [ Tue May 23, 2017 2:45 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

Code:
deps/mozilla/js/src/Makefile.in:917:CXXFLAGS += -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1
Image

Author:  zevans [ Wed May 31, 2017 9:03 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

Yep - something weird is going on - haven't figured out what yet! Suspect autoconf or the configure script is guessing something wrong...

Author:  Getafix [ Thu Jun 01, 2017 9:59 am ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

@zevans
Be very cautious fiddling with compiler and linker options, though.
If your environment is actually ignoring options defined in the distributed makefiles,
you risk ending-up with a non compatible binary demonstrating wrong behavior during execution;
and "wrong" can just and simply mean "different" and not necessarily an observable erroneous behavior. :!:

You are most probably already aware of that, but, I just felt that it needed it's own place in this thread,
emphasizing the risk, for the rest of us that are not that much keen on compilers and linkers. :oops:

Author:  Commander_X [ Fri Jul 07, 2017 6:33 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

Quick question regarding the recent distros: are there any known issues when using more recent gnustep (in my case 1.25.0) and/or gcc (5.3.0 here) on a x86 system?

The reason I'm asking this question is that I'm successfully compiling with the above versions (having use_deps=yes debug=no in make's command line), but oolite.app/oolite would segfault when trying to launch.

Details:
I also have a x86_64 system where things go smoothly.

Most notable differences (besides default libraries, due to OS versions -- one is slackware64 --x86_64 -- (almost) 14.1, and the one I'm interested in is slackware -- x86 -- 14.2):

x86_64 (working):
Code:
gnustep-make: 2.6.6
gnustep: 1.24.6
gcc: 4.8.2
x86 (not working):
Code:
gnustep-make: 2.7.0
gnustep: 1.25.0
gcc: 5.3.0
A binary release of nightly latest trunk runs correctly on this system.

"ldd" on oolite.app/oolite shows that on x86 system, the exe is picking more libs from Oolite's Linux-deps than the one on the x86_64 one:

the common set of deps llibraries picked by all (and the only libraries picked by x86_64):
Code:
libSDL-1.2.so.0
libopenal.so.1
libz.so.1
libvorbisfile.so.3
libpng14.so.14
libespeak.so.1
libvorbis.so.0
libogg.so.0
libportaudio.so.2
extras for non working x86:
Code:
libgmp.so.10
libgnutls.so.30
libnettle.so.6
libhogweed.so.4
extras for the nigthly:
Code:
libgnustep-base.so.1.20
libplds4.so.0d
libplc4.so.0d
libnspr4.so.0d
libobjc.so.2
libffi.so.4

One fix I tried was to bring the missing library links to lib_linker, but it seems they are still not picked during linking.

Author:  Getafix [ Tue Jul 11, 2017 8:41 am ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

@Commander_X
Could you upload somewhere the ./configure log, and share a link for me to download, for the gnustep library?
I am asking this, because I presume that being in slackware you build it on your own.

In the meantime, I am also preparing some instructions, for you to give me the dependencies of your oolite executable in my preferred hierarchical order.

Author:  Commander_X [ Tue Jul 11, 2017 4:45 pm ]
Post subject:  Re: Compiling on recent (2017) distros - GCC 6.x issues

Quote:
@Commander_X
Could you upload somewhere the ./configure log, and share a link for me to download, for the gnustep library?
I am asking this, because I presume that being in slackware you build it on your own.
Presumption confirmed. Here you'll have a .tar.gz file containing both files fresh from the build directory.
Quote:
In the meantime, I am also preparing some instructions, for you to give me the dependencies of your oolite executable in my preferred hierarchical order.
Looking forward for these.

FYI I've "advanced" a bit doing a sort of "hacking surgery":
- presented gnustep-base from deps/Linux-deps/x86/lib_linker as libgnustep-base.so ("ln -s" in lib_linker) -- this allowed the library to be picked by the linker, but there is a warning during linking saying that "libobjc.so.2 may conflict with libobjc.so.4".
- tried the same trick as above for nspr4 & co. (even replacing the `nspr-config --libs` in GNUmakefile with a hand crafted set of -L and -l options) -- but these libraries seem to elude my attempts; after linking, still the system ones are taken as opposed to those provided by the deps.
It seems that bringing gnustep-base into the mix like above, really messes up things -- with this setup no logs are created by the oolite when trying to launch.

Page 2 of 2 All times are UTC
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/