sempr-tk / sempr

SEMPR - Semantic Environment Mapping, Processing and Reasoning
BSD 3-Clause "New" or "Revised" License
7 stars 1 forks source link

Ubuntu 18.04 Support #41

Closed ctieben closed 6 years ago

ctieben commented 6 years ago

There is an issue with the current (July 2018) odb package for ubuntu bionic (2.4.0-6) with GCC7. In this situation the odb compiler could not generate valid odb_gen files. You will get following message if you try to compile it: db pragma 'type' is not associated with a declaration

These issue is fixed in the latest debian odb package (2.4.0-8). But this is until now not ported to ubuntu (and will not work either).

So you can try to use the default package from CodeSynthesis with there internal gcc copy and plugin. But than you will receive following error:

[build] make[2]: *** [odb_gen/PrefixAssignedIDs_odb.cpp] Error 1
[build] In file included from /usr/lib/odb/x86_64-linux-gnu/include/c++/4.9.3/cwchar:44:0,
[build]                  from /usr/lib/odb/x86_64-linux-gnu/include/c++/4.9.3/bits/postypes.h:40,
[build]                  from /usr/lib/odb/x86_64-linux-gnu/include/c++/4.9.3/bits/char_traits.h:40,
[build]                  from /usr/lib/odb/x86_64-linux-gnu/include/c++/4.9.3/string:40,
[build]                  from <standard-odb-prologue>:7:
[build] /usr/lib/odb/x86_64-linux-gnu/lib/gcc/x86_64-linux-gnu/4.9.3/include-fixed/wchar.h:175:22: fatal error: xlocale.h: No such file or directory
[build]  # include <xlocale.h>
[build]                       ^

because glibc 2.26 removed , see https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.h.27

Even if you copy the include in the directory you will get some compiler errors if you dont use the internal compiler version to compile your project!

So currently I could not find a way to compile SEMPR on Ubuntu 18.04.

niniemann commented 6 years ago

Have you tried to actually compile the odb compiler from source? https://www.codesynthesis.com/products/odb/doc/install-unix.xhtml https://www.codesynthesis.com/products/odb/download.xhtml

ctieben commented 6 years ago

Yes I did and I got a lot compiler errors by this try. (with the default gcc of 18.04 : GCC-7)

niniemann commented 6 years ago

Just for the record (because I think you already found it): This problem is discussed on the odb mailing list. The problem seems to be that your newer major version of gcc breaks the old API on which the odb compiler depends. They mentioned that you could either fall back to gcc5, or try a newer not-yet-released (?) version of odb, as described here: https://www.codesynthesis.com/pipermail/odb-users/2018-June/004039.html

niniemann commented 6 years ago

Closing this because it's not an issue we have any influence on -- it's an odb <-> gcc thing.

ctieben commented 6 years ago

There are comparable issues with Arch (see: https://aur.archlinux.org/packages/odb/ ) There GCC Plugin Interface seems to be changed in GCC 7 and in 8 (only 11 month between this two major releases, see: https://gcc.gnu.org/develop.html#timeline)

Note: GCC and CLANG are under pressure because of the new and shorter releases of C++ and the modern languages like go and rust.

ctieben commented 6 years ago

I have report this bug to the Ubuntu team. See: https://bugs.launchpad.net/ubuntu/+source/odb/+bug/1788161

ctieben commented 6 years ago

Edit: Workaround moved to Wiki

mmaurus commented 5 years ago

Is there any update? Can this issue be solved automatically using autoproj?

niniemann commented 5 years ago

Sorry, no update. All I know is in the Wiki-entry @ctieben linked in the previous comment. I'm still on 16.04 and thus don't have that problem...

Regarding autoproj: I think you already started (?) an alternative package_set with gcc5 and odb? How's it going?

mmaurus commented 5 years ago

Not going well... Installing debian packages from external sources using autoproj is not a good way. And compiling it from source does not work (undefined symbols and stuff...)

Am 30.07.19 um 14:53 schrieb niniemann:

Sorry, no update. All I know is in the Wiki-entry @ctieben https://github.com/ctieben linked in the previous comment. I'm still on 16.04 and thus don't have that problem...

Regarding autoproj: I think you already started (?) an alternative package_set with gcc5 and odb? How's it going?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sempr-tk/sempr/issues/41?email_source=notifications&email_token=ACU6NZQT7JKO3B6IAGZ4AJTQCA2ULA5CNFSM4FMMYWUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3D3T7I#issuecomment-516405757, or mute the thread https://github.com/notifications/unsubscribe-auth/ACU6NZV4R5FHITDCRLGD763QCA2ULANCNFSM4FMMYWUA.

-- Michael Maurus Team Applied Science in Space

Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany

Tel.: +49 421 178 45-4196 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: michael.maurus@dfki.de

Weitere Informationen: http://www.dfki.de/robotik

Deutsches Forschungszentrum für Künstliche Intelligenz GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany Geschäftsführung: Prof. Dr. Jana Koehler (Vorsitzende) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313

niniemann commented 5 years ago

I'm not sure how I can help you there, as I neither have a system with 18.04 nor the time to work on this. :-/ I can only suggest a quick hack: Remove the odb-dependency from the sempr-manifest so that autoproj doesn't constantly try to install it, and follow the wiki entry -- i.e. install http://de.archive.ubuntu.com/ubuntu/pool/universe/o/odb/odb_2.4.0-4build1_amd64.deb with dpkg and apt-mark hold.

LeCrucien commented 4 years ago

I am using g++-7.4, and having the same issue. I tried building the ODB compiler from source. Unfortunately, it failed. I posted the error below. Has anyone succesfully build odb compiler from source? If so, I would appreciate it if you share the steps you took.

./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for ar... ar checking the archiver (ar) interface... ar checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate configure: creating ./config.lt config.lt: creating libtool checking whether g++ supports plugins... yes checking whether to install ODB plugin into default GCC plugin directory... no checking for GCC plugin headers... no configure: error: GCC plugin headers not found; consider installing GCC plugin development package

mmaurus commented 4 years ago

For this, you have to install the package "gcc-7-plugin-dev" using sudo apt install. But I couldn't get it working. Whats works is doing it like described here: https://github.com/sempr-tk/sempr/wiki/SEMPR-on-Ubuntu-18.04

ctieben commented 4 years ago

I also tried it a few month ago without success. After some investigation I figure out that this is an issue between the newer gcc versions (>= 6) and odb 2.4.

This issue is known by the odb team, see: https://www.codesynthesis.com/pipermail/odb-users/2018-June/004031.html

And there is a beta version of odb 2.5 available that may work (since over 2 years) https://codesynthesis.com/~boris/tmp/odb/pre-release/

But I didn’t try it yet and as long as this is a beta version and not available in any distros this couldn’t be a main dependency. As long as this take, please use the workaround from the wiki page.

@niniemann In some point in the future we have to think about an alternative for odb if there isnt any progress.

ctieben commented 4 years ago

The latest debian stable package of odb fixed this issue for GCC8. (from 29.12.2018) I update the workaround to upgrade to this package instead of downgrade to xenia.

This isn't an issue in Debian 10 (Buster) and so Ubuntu 19.04 (and hopefully in 20.04 LTS) anymore. In this distros it will work without the odb workaround with a gcc8 or gcc9 compiler. But you have to use a self compiled version of soprano with qt5, see #71

ctieben commented 4 years ago

By the way Code Synthesis announced ODB 2.5.0 beta version on there news section and they still work on it. See: https://git.codesynthesis.com/cgit/odb/odb/

This version seems to support GCC9 with C++17 parts. (at least GCC >=5 is needed)