New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GCC 5 #1965

Merged
merged 1 commit into from Sep 5, 2016

Conversation

Projects
None yet
6 participants
@alarcher
Contributor

alarcher commented May 8, 2016

For testing:

  • mediated links are not activated such that GCC 5.x just lives in /usr/gcc/5
  • some patches are imported from solaris-userland

I am interested in testing OpenMP 4.0 support on scientific computing code: I share the recipe so that people can conduct their own experiments.

Note: the upstream x11 gate just switched to GCC 5.3.


GCC 5.4 test suite results:

                === gcc Summary ===

# of expected passes            112190
# of unexpected failures        61
# of unexpected successes       20
# of expected failures          284
# of unsupported tests          1689

                === g++ Summary ===

# of expected passes            84661
# of unexpected failures        891
# of expected failures          288
# of unresolved testcases       10
# of unsupported tests          3443

                === gfortran Summary ===

# of expected passes            49255
# of unexpected failures        4
# of expected failures          65
# of unsupported tests          217

                === objc Summary ===

# of expected passes            2893
# of unexpected failures        1
# of expected failures          6
# of unsupported tests          74

To be compared with results provided by Ubuntu 16.04 x86_64-linux-gnu


                === gcc Summary for unix ===

# of expected passes            120318
# of unexpected failures        286
# of expected failures          281
# of unresolved testcases       96
# of unsupported tests          1798

                === g++ Summary for unix ===

# of expected passes            93026
# of unexpected failures        12
# of unexpected successes       2
# of expected failures          342
# of unresolved testcases       1
# of unsupported tests          3815

                === gfortran Summary for unix ===

# of expected passes            49674
# of expected failures          79
# of unsupported tests          71

                === objc Summary for unix ===

# of expected passes            3010
# of expected failures          6
# of unsupported tests          74
@pyhalov

This comment has been minimized.

Contributor

pyhalov commented May 8, 2016

As for mediators, we need to add mediated links, but set mediator priority=vendor for gcc 4.9, like python 2.6 does (see https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/transforms/defaults#L132 ).

Another question is what to do with runtimes? Shouldn't we deliver them in /usr/lib or should we use gcc-05-LINK_LIBGCC_SPEC.diff from SFE? I see that you deliver runtimes in usr/gcc/5.3/lib/, but will they be actually used in runtime? If they will, shouldn't they be splitted to separate packages?

@alarcher

This comment has been minimized.

Contributor

alarcher commented May 8, 2016

OK.

  • I can fix the mediated links.
  • Since I am testing for now I set the ld flags accordingly. I have no idea about the best way so I'll follow your advice.

How is it done with gcc-3 ? They are in the same situation since gcc-53 is not the default compiler.

@alarcher alarcher force-pushed the alarcher:gcc53 branch from c57ad17 to b1d4738 May 8, 2016

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented May 8, 2016

gcc 3 runtime lives in usr/gcc/3.4/lib, and gcc doesn't deliver mediated links.
Also it seems gcc 3.4 adds implicit -R/usr/gcc/3.4/lib to ldflags (see patches/sol2.h.patch, patches/i386.sol2-10.h.patch).

@alarcher alarcher force-pushed the alarcher:gcc53 branch 2 times, most recently from 8ba01de to edfcb51 May 8, 2016

@alarcher alarcher changed the title from Add GCC 5.3.0 (WIP) to Add GCC 5.3.0 May 9, 2016

@alarcher

This comment has been minimized.

Contributor

alarcher commented May 9, 2016

Test failure in libiberty d-demangle due to non-portable code in the test: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=30379291886a171e6dc202122bc1c583318c2e17

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented May 17, 2016

It's expected that a lot of software is not ready for c99 and have _XOPEN_SOURCE issues, but some fails are more interesting - for example, clearly incorrect behavior of strgen from components/games/openttd/game (influenced by oi-uselrand default LDFLAGS) and core dump of powerdns recursor (#1988).

@jeffpc

This comment has been minimized.

Collaborator

jeffpc commented May 20, 2016

Random thought ... if we are supporting multiple compilers (and using mediators to select the default one), it'd still be nice to have an easy way to run a specific version. Specifically, I'm thinking that it'd be nice to have some additional symlinks in /usr/bin. E.g.,

  • /usr/bin/gcc-5.3 -> ../gcc/5.3/bin/gcc
  • /usr/bin/gcc-4.9 -> ../gcc/4.9/bin/gcc

I realize this is not directly related to gcc 5.3... just dumping my thought before I lose it. :)

@DrLou

This comment has been minimized.

Contributor

DrLou commented May 20, 2016

+++ I like the idea.

Some things we do will likely require features of newer gcc(s), irrespective of our OS' preferred version.

Lou Picciano

----- Original Message -----

From: "jeffpc" notifications@github.com
To: "OpenIndiana/oi-userland" oi-userland@noreply.github.com
Sent: Friday, May 20, 2016 10:52:07 AM
Subject: Re: [OpenIndiana/oi-userland] Add GCC 5.3.0 (#1965)

Random thought ... if we are supporting multiple compilers (and using mediators to select the default one), it'd still be nice to have an easy way to run a specific version. Specifically, I'm thinking that it'd be nice to have some additional symlinks in /usr/bin. E.g.,

* /usr/bin/gcc-5.3 -> ../gcc/5.3/bin/gcc 
* /usr/bin/gcc-4.9 -> ../gcc/4.9/bin/gcc 

I realize this is not directly related to gcc 5.3... just dumping my thought before I lose it. :)


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

@alarcher

This comment has been minimized.

Contributor

alarcher commented May 20, 2016

Yes I like it as well.

@tomww

This comment has been minimized.

tomww commented May 21, 2016

The functionality of a symlink like /usr/bin/gcc-5.3 and /usr/bin/gcc-4.9 can easily be achieved by:
export CC=/usr/gcc/4.9/bin/gcc
If the compiler is named /usr/bin/gcc-4.9, then you must set export CC=gcc-4.9 in any case, to actually use gcc-4.9 and not using default name "gcc".

So I would deliver in layers:
One layer (package "gcc") on top only delivers the default access to the compiler (not the runtime!), like (mediated) symlink /usr/bin/gcc pointing to /usr/gcc/4.9/bin/gcc
One layer down, the package gcc-49 delivers real files, everything goes into /usr/gcc/4.9/

I would remove unused /usr/gcc/4.9/lib/<libgcc_s.so*|libstdc++.so.6*> from the compiler package gcc and make sure, those files are only delivered once in the runtime package.

@jeffpc

This comment has been minimized.

Collaborator

jeffpc commented May 21, 2016

Yeah, I know you can invoke the compiler version directly like that. I just like the symlink idea a bit better because I can rely on $PATH without tweaking it - and that allows me to be lazy and type: gcc- to see available versions. Also being able to rely to $PATH makes quick tests easier. E.g.,

CC=gcc-5.3 gmake clean all

vs. having to type in the whole path like you suggested.

It's a minor difference, but it's one thing I miss from my time as a Debian user.

@alarcher alarcher force-pushed the alarcher:gcc53 branch from 4ce425b to c74cc7a Jun 17, 2016

@alarcher alarcher changed the title from Add GCC 5.3.0 to Add GCC 5 Aug 13, 2016

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 14, 2016

GCC 5.3 happily throws internal compiler error with FORTRAN code from NAS Parallel Benchmark and C benchmark code while GCC 5.4 survives.

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Aug 14, 2016

Do we need both?

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 14, 2016

No we do not and since GCC changed the numbering scheme GCC 5.4 is actually the latest bug fix release in the 5.x series: <major>.<minor>.<patch> -> <version>.<patch>.
I will remove 5.3 since 5.4 fixes the internal compiler error issues.
I need to change the numbering scheme to reflect that.
You can see Debian for instance: https://packages.debian.org/sid/i386/gcc-5/filelist.
Do you prefer/usr/gcc/5 or /usr/gcc/5.0 as prefix ?

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Aug 14, 2016

/usr/gcc/5 if they are compatible

@alarcher alarcher force-pushed the alarcher:gcc53 branch from 4fea737 to e70d1e5 Aug 15, 2016

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 15, 2016

And now after readding the usual patches gfortran throws an internal compiler error for any file... I do not get it...

@tomww

This comment has been minimized.

tomww commented Aug 15, 2016

A note about SFE-built gcc, I'm planning to move the SFE gcc files to
/usr/gcc-sfe/5 (5.x series)
or
/usr/gcc-sfe/4.9 (4.x series)
And keep the concept of setting RPATH in binaries to load the runtime from the compiler private directory, with a fallback (modeled after LINK_LIBGCC_SPEC patch)
RPATH /usr/gcc-sfe/5/lib:/usr/gcc-sfe/lib:/usr/gcc/lib
the last part is tribute to compatibility of old SFE binaries and a system where old gcc runtime is uninstalled with RPATH not pointing to new locations /usr/gcc-sfe/5/lib:/usr/gcc-sfe/lib

About mediators I have to think but would prepare then in a way so that user could make SFE-gcc the system default in /usr/bin/gcc | g++ for instance (default: not).

@tomww

This comment has been minimized.

tomww commented Aug 15, 2016

Alarcher: Do you happen to have a pastebin of the errors? Interesting would be, if the gfortran stubles over wrong runtime libs.
LD_DEBUG=files,libs gfortran
should reveral which libs are loaded.

- %{!YP,*:%{p|pg:-Y P,%R/usr/lib/libp%R/lib:%R/usr/lib} \
- %{!p:%{!pg:-Y P,%R/lib:%R/usr/lib}}}"
+ %{!YP,*:%{p|pg:-Y P,%R/usr/gcc/5/lib:%R/lib:%R/usr/lib -R %R/usr/gcc/5/lib} \
+ %{!p:%{!pg:-Y P,%R/usr/gcc/5/lib:%R/lib:%R/usr/lib -R %R/usr/gcc/5/lib}}}"

This comment has been minimized.

@pyhalov

pyhalov Aug 15, 2016

Contributor

Please, also add -L%R/usr/gcc/5/lib , as /usr/lib/ still has gcc4 runtime.

This comment has been minimized.

@alarcher

alarcher Aug 15, 2016

Contributor

-Y P has the same effect but restricts to the list of directories passed as argument. Adding -L would be redundant.

%{R*} \
- %{!YP,*:%{p|pg:-Y P,%R/usr/lib/libp/" ARCH64_SUBDIR ":%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR "} \
- %{!p:%{!pg:-Y P,%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR "}}}"
+ %{!YP,*:%{p|pg:-Y P,%R/usr/gcc/5/lib/" ARCH64_SUBDIR ":%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR " -R %R/usr/gcc/5/lib/" ARCH64_SUBDIR "} \

This comment has been minimized.

@pyhalov

pyhalov Aug 15, 2016

Contributor

same goes here

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 15, 2016

@tomww Thanks for the note about gcc-sfe, it sounds very good.

@alarcher alarcher force-pushed the alarcher:gcc53 branch from e70d1e5 to 3554091 Aug 15, 2016

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 16, 2016

Latest GCC 5.4 build test suite results.


                === gcc Summary ===

# of expected passes            112193
# of unexpected failures        58
# of unexpected successes       20
# of expected failures          284
# of unsupported tests          1689

                === g++ Summary ===

# of expected passes            85580
# of unexpected failures        21
# of expected failures          288
# of unsupported tests          3443

                === gfortran Summary ===

# of expected passes            49255
# of unexpected failures        4
# of expected failures          65
# of unsupported tests          217

                === objc Summary ===

# of expected passes            3010
# of expected failures          6
# of unsupported tests          74

@xen0l

This comment has been minimized.

Contributor

xen0l commented Aug 17, 2016

What else should be done to better test this?

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 17, 2016

I would suggest to merge the PR and advertise gcc 5.4 as experimental-only-use-to-provide-feedback so we can test the binaries and collect data.
Test suite results are decent and some failures may be fixed easily: mpc failures are bogus due to the buildsystem picking the wrong gmp and libiberty demangle failures are actually due to the tests.
In the mean time I will send debugging data to Rich Lowe to investigate ld's behaviour.

@xen0l

This comment has been minimized.

Contributor

xen0l commented Aug 17, 2016

@pyhalov are you OK with that?

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Aug 17, 2016

@alarcher , have you looked at pdns-recursor or openttd?

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Aug 17, 2016

The issue I'm especially interested in - if you add gcc -L/usr/lib something.c -o bla, will link editor pick GCC 4 or 5 libs?

@alarcher alarcher added the needs_work label Aug 17, 2016

@alarcher alarcher force-pushed the alarcher:gcc53 branch from eb234f6 to d47d798 Aug 17, 2016

@alarcher alarcher force-pushed the alarcher:gcc53 branch from d47d798 to 3773957 Aug 29, 2016

@alarcher alarcher removed the needs_work label Aug 29, 2016

@xen0l

This comment has been minimized.

Contributor

xen0l commented Aug 30, 2016

@alarcher any news on this? /cc @pyhalov

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 30, 2016

Fixes by richlowe are only available since yesterday on Hipster.
I am rebuilding now and if nothing bad shows up we should merge.

@alarcher

This comment has been minimized.

Contributor

alarcher commented Aug 30, 2016

@pyhalov @xen0l Today's build tested on GCC test suite, pdns_recursor and openmp test suite.
So I would say mergy mergy if your testing is similar.

                === gcc Summary ===

# of expected passes            112158
# of unexpected failures        58
# of unexpected successes       20
# of expected failures          284
# of unsupported tests          1700

                === g++ Summary ===

# of expected passes            85580
# of unexpected failures        21
# of expected failures          288
# of unsupported tests          3443

                === gfortran Summary ===

# of expected passes            49255
# of unexpected failures        4
# of expected failures          65
# of unsupported tests          217

                === objc Summary ===

# of expected passes            3010
# of expected failures          6
# of unsupported tests          74

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Aug 31, 2016

Tried to build oi-userland. So far one issue (in desktop/e/efl):
/usr/gcc/5/include/c++/5.4.0/bits/stl_algo.h:66:35: fatal error: bits/uniform_int_dist.h: No such file or directory

Does gcc miss some headers? Seems so. Please, check sample-manifest

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Sep 1, 2016

--- oi-userland/components/developer/gcc-5/gcc-5.p5m        2016-09-01 09:53:31.236443691 +0300
+++ oi-userland/components/developer/gcc-5/gcc-5.p5m      2016-09-01 10:05:20.220265581 +0300
@@ -262,6 +262,7 @@
 file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/streambuf.tcc
 file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/streambuf_iterator.h
 file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/stringfwd.h
+file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/uniform_int_dist.h
 file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/unique_ptr.h
 file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/unordered_map.h
 file path=usr/gcc/5/include/c++/$(COMPONENT_VERSION)/bits/unordered_set.h
@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Sep 1, 2016

Further issues:

EFL_RUN_IN_TREE=1 ../src/bin/eolian_cxx/eolian_cxx -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/eo -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/evas/canvas -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/edje -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/efl/interfaces -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/ecore_audio -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/ecore -I/export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/ecore_con -o lib/ecore_audio/ecore_audio.eo.hh /export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/efl-1.12.3/src/lib/ecore_audio/ecore_audio.eo
ld.so.1: eolian_cxx: fatal: libstdc++.so.6: version 'GLIBCXX_3.4.21' not found (required by file /export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/build/i86/src/bin/eolian_cxx/.libs/eolian_cxx)
ld.so.1: eolian_cxx: fatal: libstdc++.so.6: open failed: No such file or directory
ld.so.1: eolian_cxx: fatal: relocation error: file /export/home/alp/srcs/local/oi-userland/components/desktop/e/efl/build/i86/src/bin/eolian_cxx/.libs/eolian_cxx: symbol _ZSt4cout: referenced symbol not found
make[5]: *** [Makefile:33667: lib/ecore_audio/ecore_audio.eo.hh] Killed
make[4]: *** [Makefile:31933: all-recursive] Error 1
make[3]: *** [Makefile:11593: all] Error 2
make[2]: *** [Makefile:2284: all-recursive] Error 1
make[1]: *** [Makefile:1514: all] Error 2

$ elfdump bin/eolian_cxx/.libs/eolian_cxx  |grep PATH
# nothing

So, RPATH to libstdc++ is not encoded into binary

@pyhalov pyhalov added the needs_work label Sep 1, 2016

@alarcher

This comment has been minimized.

Contributor

alarcher commented Sep 1, 2016

@pyhalov but tomww asked me to remove the patch to add rpath?

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Sep 1, 2016

It could work if old patch for LINK_LIBGCC_SPEC worked, but it doesn't

@alarcher alarcher force-pushed the alarcher:gcc53 branch from 3773957 to 48fa5a0 Sep 2, 2016

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Sep 5, 2016

diff -ur /dev/null patches/002-ld-flags.patch 
--- /dev/null   2016-09-05 17:37:55.000000000 +0300
+++ patches/002-ld-flags.patch  2016-09-01 11:09:56.365121906 +0300
@@ -0,0 +1,24 @@
+--- ./gcc/config/sol2.h.orig   2016-05-08 21:13:10.810423614 +0200
++++ ./gcc/config/sol2.h        2016-05-08 21:16:55.681535743 +0200
+@@ -195,8 +195,8 @@
+   "%{G:-G} \
+    %{YP,*} \
+    %{R*} \
+-   %{!YP,*:%{p|pg:-Y P,%R/usr/lib/libp%R/lib:%R/usr/lib} \
+-         %{!p:%{!pg:-Y P,%R/lib:%R/usr/lib}}}"
++   %{!YP,*:%{p|pg:-Y P,%R/usr/gcc/5/lib:%R/lib:%R/usr/lib -R %R/usr/gcc/5/lib -L %R/usr/gcc/5/lib} \
++         %{!p:%{!pg:-Y P,%R/usr/gcc/5/lib:%R/lib:%R/usr/lib -R %R/usr/gcc/5/lib -L %R/usr/gcc/5/lib}}}"
+ 
+ #undef LINK_ARCH32_SPEC
+ #define LINK_ARCH32_SPEC LINK_ARCH32_SPEC_BASE
+@@ -208,8 +208,8 @@
+   "%{G:-G} \
+    %{YP,*} \
+    %{R*} \
+-   %{!YP,*:%{p|pg:-Y P,%R/usr/lib/libp/" ARCH64_SUBDIR ":%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR "}       \
+-         %{!p:%{!pg:-Y P,%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR "}}}"
++   %{!YP,*:%{p|pg:-Y P,%R/usr/gcc/5/lib/" ARCH64_SUBDIR ":%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR " -R %R/usr/gcc/5/lib/" ARCH64_SUBDIR " -L %R/usr/gcc/5/lib/" ARCH64_SUBDIR "}  \
++         %{!p:%{!pg:-Y P,%R/usr/gcc/5/lib/" ARCH64_SUBDIR ":%R/lib/" ARCH64_SUBDIR ":%R/usr/lib/" ARCH64_SUBDIR " -R %R/usr/gcc/5/lib/" ARCH64_SUBDIR " -L %R/usr/gcc/5/lib/" ARCH64_SUBDIR "}}}"
+ 
+ #undef LINK_ARCH64_SPEC
+ #ifndef USE_GLD

Do we need test results in such form? Perhaps, it's better to converting them to standard oi-userland test representation (so that gmake test just worked) or just drop them?

@alarcher

This comment has been minimized.

Contributor

alarcher commented Sep 5, 2016

I published the test results in a separate commit if people wanted to compare and such that it can be dropped before merge.
So are we just re-adding the initial gcc3-style patch?

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Sep 5, 2016

Let's drop test results before integration. And as we don't have better solution for now, we need that patch, otherwise binaries fail to compile (or run).

@alarcher alarcher force-pushed the alarcher:gcc53 branch from 48fa5a0 to 93a4100 Sep 5, 2016

@alarcher

This comment has been minimized.

Contributor

alarcher commented Sep 5, 2016

Back to square one eh ;) I pushed your patch.

@pyhalov pyhalov removed the needs_work label Sep 5, 2016

@pyhalov

This comment has been minimized.

Contributor

pyhalov commented Sep 5, 2016

I think it can be merged now

@pyhalov pyhalov merged commit 0c05a36 into OpenIndiana:oi/hipster Sep 5, 2016

@alarcher alarcher deleted the alarcher:gcc53 branch May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment