Bug 639278 – sys-devel/gcc-5.4.0-r3 USE=gcj with sys-libs/glibc-2.26 - In file included from ../../../gcc-6.4.0/libjava/prims.cc:26:0: ../../../gcc-6.4.0/libjava/prims.cc: In function 'void _Jv_catch_fpe(int, siginfo_t*, void*)': ./include/java-signal.h:32:26: error:

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Mads 2017-11-30 10:39:10 UTC]

You get a compilation failure similar to this (log taken from https://github.com/NixOS/nixpkgs/issues/31447):

In file included from ../../../gcc-6.4.0/libjava/prims.cc:26:0:
../../../gcc-6.4.0/libjava/prims.cc: In function 'void _Jv_catch_fpe(int, siginfo_t*, void*)':
./include/java-signal.h:32:26: error: invalid use of incomplete type 'struct _Jv_catch_fpe(int, siginfo_t*, void*)::ucontext'
   gregset_t &_gregs = _uc->uc_mcontext.gregs;    \
                          ^
../../../gcc-6.4.0/libjava/prims.cc:192:3: note: in expansion of macro 'HANDLE_DIVIDE_OVERFLOW'
   HANDLE_DIVIDE_OVERFLOW;
   ^~~~~~~~~~~~~~~~~~~~~~
./include/java-signal.h:31:10: note: forward declaration of 'struct _Jv_catch_fpe(int, siginfo_t*, void*)::ucontext'
   struct ucontext *_uc = (struct ucontext *)_p;    \
          ^
../../../gcc-6.4.0/libjava/prims.cc:192:3: note: in expansion of macro 'HANDLE_DIVIDE_OVERFLOW'
   HANDLE_DIVIDE_OVERFLOW;
   ^~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [Makefile:9968: prims.lo] Error 1
make[3]: Leaving directory '/tmp/nix-build-gcj-6.4.0.drv-0/build/x86_64-unknown-linux-gnu/libjava'
make[2]: *** [Makefile:10281: all-recursive] Error 1
make[2]: Leaving directory '/tmp/nix-build-gcj-6.4.0.drv-0/build/x86_64-unknown-linux-gnu/libjava'
make[1]: *** [Makefile:18651: all-target-libjava] Error 2
make[1]: Leaving directory '/tmp/nix-build-gcj-6.4.0.drv-0/build'
make: *** [Makefile:21927: bootstrap] Error 2
builder for ‘/nix/store/sfnsm5lzd622hihczmyqscx694il36ad-gcj-6.4.0.drv’ failed with exit code 2


Fix from NixOS provided here: https://github.com/NixOS/nixpkgs/pull/31455/commits/7112718a20a0f9698a17edff96e22ea386cf0578

[Comment 1 Preston Crow 2018-01-09 20:28:56 UTC]

I was hoping to get a gcj compiler to work to build pdftk (which I suspect is the only reason anyone is looking at this bug).  I tried building gcc-4.9.4 in the hopes that it would work, but it has the exact same issue, so anyone else in the same boat can skip trying that.

[Comment 2 Attila Tóth 2018-01-09 21:56:28 UTC]

Created attachment 514032 [details, diff]
struct-ucontext-libjava.patch

NixOS fix adapted to gentoo sys-devel/gcc-5.4.0

[Comment 3 Attila Tóth 2018-01-09 21:57:21 UTC]

Created attachment 514034 [details, diff]
gcc6_nopie_oldergcc2.patch

I'm not sure if this one is needed for everone...

[Comment 4 Attila Tóth 2018-01-09 22:03:00 UTC]

(In reply to Preston Crow from comment #1)
> I was hoping to get a gcj compiler to work to build pdftk (which I suspect
> is the only reason anyone is looking at this bug).  I tried building
> gcc-4.9.4 in the hopes that it would work, but it has the exact same issue,
> so anyone else in the same boat can skip trying that.

pdftk: exactly. Give the patches I attached a try.
How good it would be to make pdftk compatible with gcc-6/7!
Debian's and Arch's pdftk-2.02 depends on gcc-6. I think we should move forward and apply a treatment on pdftk.

[Comment 5 Mihai Moldovan 2018-01-10 00:08:11 UTC]

The ucontext patch looks good. This is what I have crafted myself individually and seems to get the job done.

> How good it would be to make pdftk compatible with gcc-6/7!

Might be possible for GCC 6, but definitely not GCC 7. GCC dropped support for GCJ in version 7 completely - and as far as I remember partly in 6 already. There probably is a reason why gcj cannot be enabled in Gentoo's GCC 6 package - even though it still seems to work on Debian and Arch, as you already said. Probably not without some heavy patching, though, which the maintainer(s) probably didn't want to go through just for one package.

Neither of these distributions feature gcj for GCC 7, though. That's pretty much the end of it - and by extension will be the end of pdftk, unless it is made compatible with other java compilers.

[Comment 6 Attila Tóth 2018-01-10 10:32:26 UTC]

(In reply to Mihai Moldovan from comment #5)
> The ucontext patch looks good. This is what I have crafted myself
> individually and seems to get the job done.
> 
> > How good it would be to make pdftk compatible with gcc-6/7!
> 
> Might be possible for GCC 6, but definitely not GCC 7. GCC dropped support
> for GCJ in version 7 completely - and as far as I remember partly in 6
> already. There probably is a reason why gcj cannot be enabled in Gentoo's
> GCC 6 package - even though it still seems to work on Debian and Arch, as
> you already said. Probably not without some heavy patching, though, which
> the maintainer(s) probably didn't want to go through just for one package.
> 
> Neither of these distributions feature gcj for GCC 7, though. That's pretty
> much the end of it - and by extension will be the end of pdftk, unless it is
> made compatible with other java compilers.

According to funtoo bug:
https://forums.funtoo.org/topic/247-gcc-with-gcj-for-pdftk-and-impressive/
https://bugs.funtoo.org/browse/FL-970
"This support (gcc gcj) scheduled for removal from gcc upstream too. We will look what possible to do with pdftk."
They propose mcpdf as a replacement:
https://issues.sonatype.org/browse/OSSRH-8759
https://github.com/m-click/mcpdf
But there are complaining about mcpdf...
My other option for pdf manipulation is qpdf, but I still like pdftk...

[Comment 7 Nick 2018-01-13 02:09:06 UTC]

(In reply to Mihai Moldovan from comment #5)
> The ucontext patch looks good. This is what I have crafted myself
> individually and seems to get the job done.
> 
> > How good it would be to make pdftk compatible with gcc-6/7!
> 
> Might be possible for GCC 6, but definitely not GCC 7. GCC dropped support
> for GCJ in version 7 completely - and as far as I remember partly in 6
> already. There probably is a reason why gcj cannot be enabled in Gentoo's
> GCC 6 package - even though it still seems to work on Debian and Arch, as
> you already said. Probably not without some heavy patching, though, which
> the maintainer(s) probably didn't want to go through just for one package.
> 
> Neither of these distributions feature gcj for GCC 7, though. That's pretty
> much the end of it - and by extension will be the end of pdftk, unless it is
> made compatible with other java compilers.

So far I have experienced no problems compiling gcc, pdftk, or anything else after manually unmasking the gcj use flag on =sys-devel/gcc-6.4.0, without performing any other intervention.

[Comment 8 Sergei Trofimovich (RETIRED) 2018-01-13 09:54:32 UTC]

Was fixed in bug #629502

gcc should be able to build libjava at least for
 sys-devel/gcc/gcc-4.9.4.ebuild
 sys-devel/gcc/gcc-5.4.0-r4.ebuild
 sys-devel/gcc/gcc-6.4.0-r1.ebuild

*** This bug has been marked as a duplicate of bug 629502 ***

[Comment 9 Attila Tóth 2018-01-13 14:05:53 UTC]

(In reply to Nick from comment #7)
> (In reply to Mihai Moldovan from comment #5)
> > The ucontext patch looks good. This is what I have crafted myself
> > individually and seems to get the job done.
> > 
> > > How good it would be to make pdftk compatible with gcc-6/7!
> > 
> > Might be possible for GCC 6, but definitely not GCC 7. GCC dropped support
> > for GCJ in version 7 completely - and as far as I remember partly in 6
> > already. There probably is a reason why gcj cannot be enabled in Gentoo's
> > GCC 6 package - even though it still seems to work on Debian and Arch, as
> > you already said. Probably not without some heavy patching, though, which
> > the maintainer(s) probably didn't want to go through just for one package.
> > 
> > Neither of these distributions feature gcj for GCC 7, though. That's pretty
> > much the end of it - and by extension will be the end of pdftk, unless it is
> > made compatible with other java compilers.
> 
> So far I have experienced no problems compiling gcc, pdftk, or anything else
> after manually unmasking the gcj use flag on =sys-devel/gcc-6.4.0, without
> performing any other intervention.

I've learned something new today - again, thanks!