Hi Andreas, On 05.02.18 14:13 Andreas Schwab wrote:

On Feb 05 2018, Johannes Kastl wrote:

...

So I tried to build it myself, which worked by hacking the spec and disabling some java stuff, as you can see in the revisions: https://build.opensuse.org/package/revisions/home:ojkastl_buildservice:git-l...

gcc5-go is already available in devel:languages:go/gcc5, why do you need to change anything at all?

Then let me rephase my question: How was it built there? My question was not about where to find a working gcc5-go, but more about the concept of building gcc5-go and all the stuff going on in the background. Johannes

On 05.02.18 14:27 Andreas Schwab wrote:

...

Then let me rephase my question: How was it built there?

As a subpackage of the gcc5 package.

Andreas, do you actually believe this answer is helpful? Johannes

Hi Johannes!

On Feb 5, 2018, at 2:25 PM, Johannes Kastl wrote:

Then let me rephase my question: How was it built there?

My question was not about where to find a working gcc5-go, but more about the concept of building gcc5-go and all the stuff going on in the background.

I am not sure about the specific details of the gcc package in SLE or openSUSE, but generally you do not need any version of the go compiler to build gccgo. gccgo can be compiled as long as you have a working version of gcc which is not too old. The only compiler of the gcc compiler suite that I know of which needs to be bootstrapped is gnat. You need a working Ada (gnat) compiler to build gnat. gcj, gccgo and gdc can all be built just using a C compiler. I have bootstrapped gcc in Debian on new architectures several times and so far it was always gnat that caused a circular dependency on itself if it was enabled in the gcc package. Adrian-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 05.02.18 14:37 Jordi Massaguer Pla wrote:

which error where you getting if java was enabled?

I just never got a gcc5-go package being built. To *me* this looked like it was an either-this-or-that:

# We don't want to build java %ifarch mips %define build_java 0 %define build_libjava 0 %else %define build_java 1 %define build_libjava 0%{?building_libjava:1}%{?building_libffi:1}%{?building_testsuite:1} %endif

%define build_cp 1 %define build_fortran !0%{?building_libjava:1}%{?building_libffi:1} %define build_objc !0%{?building_libjava:1}%{?building_libffi:1} %define build_objcp !0%{?building_libjava:1}%{?building_libffi:1} %define build_go !0%{?building_libjava:1}%{?building_libffi:1}

On non-mips build_java and build_libjava are set, and build_go somehow takes that into account. I had no time to deepdive there, but setting build_java and build_libjava to 0 got me a gcc5-go package... That was why I was asking for insights. ;-) Johannes

On 05.02.18 14:49 Andreas Schwab wrote:

...

On non-mips build_java and build_libjava are set, and build_go somehow takes that into account.

build_libjava and building_libjava are different macros.

NO! No really? You don't say. Wow. Honestly, why do you think I am puzzled? And why do you think I wrote "somehow takes that into account"? I had no gcc5-go package being built, then I changed the java stuff, and there was a gcc5-go package. So, somehow this seems to work. By chance, by accident, by deep cosmic whatever, I do not know. That is why I asked you guys for an explanation. But thanks, Andreas, now I know that those macros are not the same. Wow. Johannes

On Mon, 5 Feb 2018, Johannes Kastl wrote:

On 05.02.18 14:37 Jordi Massaguer Pla wrote:

...

which error where you getting if java was enabled?

I just never got a gcc5-go package being built.

To *me* this looked like it was an either-this-or-that:

...

# We don't want to build java %ifarch mips %define build_java 0 %define build_libjava 0 %else %define build_java 1 %define build_libjava 0%{?building_libjava:1}%{?building_libffi:1}%{?building_testsuite:1} %endif

%define build_cp 1 %define build_fortran !0%{?building_libjava:1}%{?building_libffi:1} %define build_objc !0%{?building_libjava:1}%{?building_libffi:1} %define build_objcp !0%{?building_libjava:1}%{?building_libffi:1} %define build_go !0%{?building_libjava:1}%{?building_libffi:1}

On non-mips build_java and build_libjava are set, and build_go somehow takes that into account. I had no time to deepdive there, but setting build_java and build_libjava to 0 got me a gcc5-go package...

That was why I was asking for insights. ;-)

Simply do not re-build gcc ;) Use what is available - SLE12 should also have gcc7-go via the toolchain module now. Short answer to your question above: there are multiple .spec files involved in a GCC build and libjava is built from a different one than go. Richard. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Tue, 6 Feb 2018, Johannes Kastl wrote:

Thanks for the answer to the java-or-go question.

As for the original question, was it by chance that changing the %define lines did get me a working gcc5-go package?

You must have misremembered. None of your two changes is required. Without them gcc5-go is created fine (I checked). Hardcoding build_go also works.

Or what is the normal process? Not that I plan to do this frequently, but I'd like to understand the mechanism behind all the %define stuff... ;-)

You seemed to have understood it actually, you just managed to confuse yourself in thinking it weren't working as you thought it did. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org