I don't like the hack to sillence warnings in unregisterised builds. Why can't we follow standard procedures and ignore the warning in an rpmlintrc file? Admittedly, I could not get it to work either but I would like to know why and not conceal a potential bug with a hack.

This package is to produce binary distributions for bootstrap where upstream does not provide any. For x86_64, i386, and ppc we are going to use upstream bindists that will not have the PIC/PIE patch. The policy in this package is to use vanilla upstream sources and patch only if ghc cannot be built at all. I also use this package to test upstreams release candidates on openSUSE.

Thanks for all that work but I am leaning towards declining your request.

Some tests are performed by OBS and cannot be filtered by rpmlint filters. Presumably this is one of them because filtering was ineffective.

The warning results from code like

int func(int a, int b) { switch((int)(a==b)) { case 0: return 42; case 1: return 0; }}

which is completely correct.

You need the PIE patch in the bootstrap compiler to be able to build the final compiler. So you cannot use the upstream packages until this is fixed upstream. And yes, not using the PIE patch results in inability to build the compiler with the bootstrap package on x86_64, arm, ppc, and s390x - unless you want to resort to hacks when building the final compiler.

Peter Trommler (ptrommler) - almost 7 years ago

For the OBS filtering: Well then let's at least add a comment why we do not filter in rpmlintrc, so we and others still know what's going on in two years from now.

Regarding PIE: I don't understand what's going on here. Can you please explain what hacks you are referring to and what is necessary to reproduce a build failure. We will eventually have to bootstrap some compiler using a non-PIE compiler because that is all we have at the moment. Where is the last non-PIE bootstrap compiler in the current setup? Factory:ghc-bootstrap (definitely non-PIE) or Factory:ghc (PIE?)?

I would like to see reasons why we have to build our own binary dists for all platforms now and I would like to know the "hacks" required in the "final compiler" to make an educated decision.

For now could you submit a separate request for the OBS filtering issue while we are discussing the PIE issue.

Thanks, Peter

A hack is

+%ifarch x86_64 %arm ppc s390x #!BuildIgnore: gcc-PIE +# With ghc-pie.patch we hopefully build a compiler that can bake pies so using +# these binaries for bootstrap will not require the above hack in the final +# compiler - unlike the upstream unpatched binaries %endif

which produces the compiler as non-pie executable.

Since ghc does not build as pie all compilers we have are non-pie.

Ultimately if you fix the ghc build system to properly pass through the flags to all libraries built with ghc you will get PIC libraries which can be built into a PIE executable and then ghc can be a PIE executable.

So to bootstrap a pie compiler you have to pass the PIC flag to the bootstrap compiler (and fix it so the flag is actually applied everywhere) so the libraries that are part of it can be linked into a pie executable.

You get a relocation error when linking a PIE executable with non-pic objects but I do not have the message at hand. It also varies per architecture.