Re: i386 bulk build failures
On 2014/02/13 08:01, Francisco de Borja Lopez Rio wrote:
It would be great to have some haskell-based stuff back for 5.5, like darcs
for example, which build fails now with:
Unlikely, to be honest. hs-vector gets slightly further if ghc is
built with the diff below, but still fails:
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ...
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
__i686.get_pc_thunk.bx
whilst processing object file
/usr/local/lib/libiconv.a
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.107
diff -u -p -r1.107 Makefile
--- Makefile12 Dec 2013 22:13:37 - 1.107
+++ Makefile13 Feb 2014 14:03:16 -
@@ -11,7 +11,7 @@ COMMENT-doc = documentation for GHC
DISTNAME = ghc-${MODGHC_VER}
PKGNAME-main = ghc-${MODGHC_VER}
-REVISION-main =1
+REVISION-main =2
PKGNAME-doc = ghc-doc-${MODGHC_VER}
REVISION-doc = 0
CATEGORIES = lang devel
Index: patches/patch-libraries_integer-gmp_gmp_ghc_mk
===
RCS file: patches/patch-libraries_integer-gmp_gmp_ghc_mk
diff -N patches/patch-libraries_integer-gmp_gmp_ghc_mk
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libraries_integer-gmp_gmp_ghc_mk 13 Feb 2014 14:03:16
-
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libraries/integer-gmp/gmp/ghc.mk.orig Thu Feb 13 03:41:22 2014
libraries/integer-gmp/gmp/ghc.mk Thu Feb 13 03:47:57 2014
+@@ -135,7 +135,7 @@ libraries/integer-gmp/gmp/libgmp.a libraries/integer-g
+ PATH=`pwd`:$$PATH; \
+ export PATH; \
+ cd gmpbuild \
+- CC=$(CC_STAGE1) NM=$(NM) AR=$(AR_STAGE1) $(SHELL) configure \
++ CC=$(CC_STAGE1) NM=$(NM) AR=$(AR_STAGE1) CFLAGS=-fno-pie -nopie
LDFLAGS=-nopie $(SHELL) configure \
+ --enable-shared=no \
+ --host=$(HOSTPLATFORM) --build=$(BUILDPLATFORM)
+ $(MAKE) -C libraries/integer-gmp/gmp/gmpbuild MAKEFLAGS=
Re: i386 bulk build failures
On Thu, Feb 13, 2014 at 02:05:59PM +, Stuart Henderson wrote: On 2014/02/13 08:01, Francisco de Borja Lopez Rio wrote: It would be great to have some haskell-based stuff back for 5.5, like darcs for example, which build fails now with: Unlikely, to be honest. hs-vector gets slightly further if ghc is built with the diff below, but still fails: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol __i686.get_pc_thunk.bx whilst processing object file /usr/local/lib/libiconv.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Unfortunately, I don't have enough knowledge about ghc's internals (general as well as the internal runtime linker) nor enough spare time to learn enough about it to get this fixed in time. The next release of ghc (7.8) will probably require real shared libraries, which I hope will make the use of rts/Linker.c obsolete. Ciao, Kili
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 10:44:49PM +0100, Matthias Kilian wrote: On Thu, Jan 02, 2014 at 04:52:51PM +0100, Matthias Kilian wrote: On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' I'll update my i386 test installation and have a look. Until then, can you point me to the log files of those two? No more need for log files, I could reproduce the problem now and it's ghci (and runghc) which is broken. A quick workaround would be to (again) change lang/ghc/ghc.port.mk to compile the Setup.hs or Setup.lhs files instead of trying to interpret them. I'll give this a try, soon. However, ports loading hs-* libraries at runtime (like www/hs-snap-loader-dynamic) will not work on i386. Any results/more work on this? It would be great to have some haskell-based stuff back for 5.5, like darcs for example, which build fails now with: === Installing hs-primitive-0.5.0.1p0 from /usr/ports/packages/i386/all/ hs-primitive-0.5.0.1p0: ok === Returning to build of hs-vector-0.10.0.1p0 === hs-vector-0.10.0.1p0 depends on: hs-primitive-=0.5.0.1,0.6 - hs-primitive-0.5.0.1p0 === hs-vector-0.10.0.1p0 depends on: ghc-=7.6.3 - ghc-7.6.3p1 === hs-vector-0.10.0.1p0 depends on: ghc-* - ghc-7.6.3p1 === hs-vector-0.10.0.1p0 depends on: haddock-* - haddock-2.13.2 === hs-vector-0.10.0.1p0 depends on: ghc-doc-* - ghc-doc-7.6.3p0 === Extracting for hs-vector-0.10.0.1p0 === Patching for hs-vector-0.10.0.1p0 === Configuring for hs-vector-0.10.0.1p0 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking /usr/ports/pobj/hs-vector-0.10.0.1/vector-0.10.0.1/Setup ... /usr/local/lib/ghc/libHSrts.a(RtsFlags.o)(.text+0x2a2): In function `copyArg': : warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/ghc/libHSrts.a(RtsUtils.o)(.text+0x2f2): In function `showStgWord64': : warning: sprintf() is often misused, please use snprintf() Configuring vector-0.10.0.1... Flags chosen: internalchecks=False, unsafechecks=False, boundschecks=True Dependency base ==4.*: using base-4.6.0.1 Dependency deepseq =1.1 1.4: using deepseq-1.3.0.1 Dependency ghc-prim -any: using ghc-prim-0.3.0.0 Dependency primitive =0.5.0.1 0.6: using primitive-0.5.0.1 Using Cabal-1.16.0 compiled by ghc-7.6 Using compiler: ghc-7.6.3 Using install prefix: /usr/local Binaries installed in: /usr/local/bin Libraries installed in: /usr/local/lib/ghc/vector-0.10.0.1 Private binaries installed in: /usr/local/libexec Data files installed in: /usr/local/share/hs-vector-0.10.0.1 Documentation installed in: /usr/local/share/doc/hs-vector-0.10.0.1 No alex found Using ar found on system at: /usr/bin/ar No c2hs found No cpphs found No ffihugs found Using gcc version 4.2.1 found on system at: /usr/bin/gcc Using ghc version 7.6.3 found on system at: /usr/local/bin/ghc Using ghc-pkg version 7.6.3 found on system at: /usr/local/bin/ghc-pkg No greencard found Using haddock version 2.13.2 found on system at: /usr/local/bin/haddock No happy found No hmake found Using hpc version 0.6 found on system at: /usr/local/bin/hpc Using hsc2hs version 0.67 found on system at: /usr/local/bin/hsc2hs No hscolour found No hugs found No jhc found Using ld found on system at: /usr/bin/ld No lhc found No lhc-pkg found No nhc98 found Using pkg-config version 0.27.1 found on system at: /usr/bin/pkg-config Using ranlib found on system at: /usr/bin/ranlib Using strip found on system at: /usr/bin/strip Using tar found on system at: /bin/tar No uhc found === Building for hs-vector-0.10.0.1p0 creating dist/build creating dist/build/autogen Building vector-0.10.0.1... Preprocessing library vector-0.10.0.1... Building library... creating dist/build /usr/local/bin/ghc --make -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/ build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -Iinternal -optP-DVECTOR_BOUNDS_CHECKS -optP -include -optPdist/build/autogen/cabal_macros.h -package-name vector-0.10.0.1 -hide-all-packages -no-user-package-db -p ackage-db dist/package.conf.inplace -package-id base-4.6.0.1-d435272bc8de1d17f3a0aacfbd562dbe -package-id deepseq-1.3.0 .1-aa1be128186a233c7290faf88620ffe5 -package-id ghc-prim-0.3.0.0-00db43fcd2f6e2a73243bdb496b765e0 -package-id primitive -0.5.0.1-260c8f143868c49f07653c18a9e6d8dc -XHaskell98 -XCPP -XDeriveDataTypeable Data.Vector.Internal.Check Data.Vector .Fusion.Util Data.Vector.Fusion.Stream.Size Data.Vector.Fusion.Stream.Monadic Data.Vector.Fusion.Stream Data.Vector.Gen eric.Mutable Data.Vector.Generic.Base Data.Vector.Generic.New Data.Vector.Generic Data.Vector.Primitive.Mutable Data.Ve ctor.Primitive Data.Vector.Storable.Internal Data.Vector.Storable.Mutable Data.Vector.Storable Data.Vector.Unboxed.Base
Re: i386 bulk build failures
I've fixed/worked-around some more. Failures from the last build: emulators/dosbox - see diff sent earlier sysutils/grub - see diff sent earlier multimedia/avidemux - could probably switch to non asm code, or use no-pie games/openarena - will probably need no-pie or rewriting asm games/megaglest/base - small asm code (cpuid flag checker) directly uses register used by PIE lang/nhc98 - segfaults in build devel/hs-ghc-paths - unhandled ELF relocation devel/hasktags - unhandled ELF relocation (and java is broken, knocking out dependent ports, including libreoffice). On 2014/01/01 21:38, Stuart Henderson wrote: Quick summary of the failures in the last i386 bulk build. Java ports are now broken on i386 as a result of JDK problems. www/chromium,proprietary: 'chrome/common/extensions/api/runtime.h' file not found - this is possibly the missing interdependency that espie just fixed. Following are PIE-related, in some cases use of -fomit-frame-pointer for i386 may help, others will need more. devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' emulators/dosbox: PIC register '%ebx' clobbered in 'asm' emulators/mupen64plus/core: now uses PIC #ifdef in src/r4300/x86/rjump.c:104 which needs newer GCC (about to send diff for this). emulators/openmsx: out of reg's emulators/xnp2: PIC register 'ebx' clobbered in 'asm' games/eduke32: out of reg's games/megaglest/base: out of reg's games/openarena: out of reg's graphics/cqcam: PIC register 'bx' clobbered in 'asm' graphics/rawstudio: out of reg's multimedia/avidemux: out of reg's sysutils/grub: GRUB requires a working absolute objcopy x11/mplayer: out of reg's x11/xdesktopwaves: PIC register 'ebx' clobbered in 'asm' Not sure about cause yet, some may be PIE-related too: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' lang/gprolog: segfault when running gplc -c --fast-math fd2c.pl lang/nhc98: segfaults in build lang/petite-chez: undefined reference to `__guard' mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. This is with the committed PIE changes only, there is a diff around to enable PIE in ports compilers too, which may expose further problems.
Re: i386 bulk build failures
On 2014/01/03 00:06, Juan Francisco Cantero Hurtado wrote: On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote: lang/petite-chez: undefined reference to `__guard' ONLY_FOR_ARCHS =i386 Hmm, FreeBSD has a port of 8.4 that at least adds amd64. The license of Petite Chez is weird and the port is very outdated. We have better scheme interpreters/compilers like gambit, chicken or racket. So, ok juanfra@ if someone wants delete the port :) Any other comments about petite-chez? I see that it also uses binary bootstraps provided by upstream and the port doesn't provide a way to regenerate them, making it at best awkward to maintain.
Re: i386 bulk build failures
Stuart Henderson st...@openbsd.org writes: On 2014/01/03 00:06, Juan Francisco Cantero Hurtado wrote: On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote: lang/petite-chez: undefined reference to `__guard' ONLY_FOR_ARCHS =i386 Hmm, FreeBSD has a port of 8.4 that at least adds amd64. The license of Petite Chez is weird and the port is very outdated. We have better scheme interpreters/compilers like gambit, chicken or racket. So, ok juanfra@ if someone wants delete the port :) Any other comments about petite-chez? I see that it also uses binary bootstraps provided by upstream and the port doesn't provide a way to regenerate them, making it at best awkward to maintain. ok to kill it. -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: i386 bulk build failures
On Tue, Jan 7, 2014 at 3:50 PM, Jérémie Courrèges-Anglas j...@wxcvbn.org wrote: Stuart Henderson st...@openbsd.org writes: On 2014/01/03 00:06, Juan Francisco Cantero Hurtado wrote: On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote: lang/petite-chez: undefined reference to `__guard' ONLY_FOR_ARCHS =i386 Hmm, FreeBSD has a port of 8.4 that at least adds amd64. The license of Petite Chez is weird and the port is very outdated. We have better scheme interpreters/compilers like gambit, chicken or racket. So, ok juanfra@ if someone wants delete the port :) Any other comments about petite-chez? I see that it also uses binary bootstraps provided by upstream and the port doesn't provide a way to regenerate them, making it at best awkward to maintain. ok to kill it. here too. ciao, David
lang/petite-chez (was: Re: i386 bulk build failures)
Juan Francisco Cantero Hurtado i...@juanfra.info wrote: lang/petite-chez: undefined reference to `__guard' ONLY_FOR_ARCHS =i386 Hmm, FreeBSD has a port of 8.4 that at least adds amd64. The license of Petite Chez is weird and the port is very outdated. We have better scheme interpreters/compilers like gambit, chicken or racket. So, ok juanfra@ if someone wants delete the port :) Let's ask the maintainer for input... cc'ed. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures
hmm, on Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson said that Following are PIE-related, in some cases use of -fomit-frame-pointer for i386 may help, others will need more. devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' emulators/dosbox: PIC register '%ebx' clobbered in 'asm' emulators/mupen64plus/core: now uses PIC #ifdef in src/r4300/x86/rjump.c:104 which needs newer GCC (about to send diff for this). emulators/openmsx: out of reg's emulators/xnp2: PIC register 'ebx' clobbered in 'asm' games/eduke32: out of reg's games/megaglest/base: out of reg's games/openarena: out of reg's graphics/cqcam: PIC register 'bx' clobbered in 'asm' graphics/rawstudio: out of reg's multimedia/avidemux: out of reg's sysutils/grub: GRUB requires a working absolute objcopy x11/mplayer: out of reg's x11/xdesktopwaves: PIC register 'ebx' clobbered in 'asm' the mpv port i submitted gets out of reg's now as well. the project told me they have added a --disable-asm configure switch (because of openbsd's old toolchain) and also they plan to move to ffmpeg stuff instead of the builtin asm stuff. working on their new release now but waf is in my way... -f -- the devil can cite scripture for his purpose.
Re: i386 bulk build failures
Stuart Henderson st...@openbsd.org wrote: Not sure about cause yet, some may be PIE-related too: These are not: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' Sporadic build failure; also happens on amd64. mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 01:52:03PM +, Christian Weisgerber wrote: Stuart Henderson st...@openbsd.org wrote: Not sure about cause yet, some may be PIE-related too: These are not: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' Sporadic build failure; also happens on amd64. mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. I Haven't seen them in the bulk build i ran with the swig update diff.. Landry
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 02:58:55PM +0100, Landry Breuil wrote: mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. I Haven't seen them in the bulk build i ran with the swig update diff.. Well, they are there anyways. I see them too.
Re: i386 bulk build failures
Stuart Henderson st...@openbsd.org wrote:
lang/nhc98: segfaults in build
NOT_FOR_ARCHS= ${LP64_ARCHS} powerpc
BROKEN-hppa=Segfault during build since the PIE switch
Do we need this for bootstrapping or reference purposes or can we
just remove it?
lang/petite-chez: undefined reference to `__guard'
ONLY_FOR_ARCHS =i386
Hmm, FreeBSD has a port of 8.4 that at least adds amd64.
Frankly, I would like to kill the remaining !LP64 and i386-only
ports. (Excluding such things as tpwireless.)
--
Christian naddy Weisgerber na...@mips.inka.de
tedu lang/nhc98 (was: i386 bulk build failures)
On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote:
lang/nhc98: segfaults in build
NOT_FOR_ARCHS= ${LP64_ARCHS} powerpc
BROKEN-hppa=Segfault during build since the PIE switch
Do we need this for bootstrapping or reference purposes or can we
just remove it?
It's not used for any bootstrapping, it just was meant as a way to
play with Haskell on at least *some* other archs than ghc runs on.
I wouldn't miss it, so feel free to mark it completely broken for
now; its removal also requires some cleanup in devel/cpphs and the
removal of devel/hmake, which I'll can take care of this evening
or tomorrow.
Ciao,
Kili
Re: i386 bulk build failures
On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' I'll update my i386 test installation and have a look. Until then, can you point me to the log files of those two? (FYI: breakage in hs-ghc-paths disables almost all hs-* libraries to be unbuildable, because they depend on haddock which depends on hs-ghc-paths) Ciao, Kili
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 04:52:51PM +0100, Matthias Kilian wrote: On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' I'll update my i386 test installation and have a look. Until then, can you point me to the log files of those two? No more need for log files, I could reproduce the problem now and it's ghci (and runghc) which is broken. A quick workaround would be to (again) change lang/ghc/ghc.port.mk to compile the Setup.hs or Setup.lhs files instead of trying to interpret them. I'll give this a try, soon. However, ports loading hs-* libraries at runtime (like www/hs-snap-loader-dynamic) will not work on i386. Ciao Kili
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 02:58:55PM +0100, Landry Breuil wrote: On Thu, Jan 02, 2014 at 01:52:03PM +, Christian Weisgerber wrote: Stuart Henderson st...@openbsd.org wrote: Not sure about cause yet, some may be PIE-related too: These are not: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' Sporadic build failure; also happens on amd64. mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. Also on amd64. Likely fallout from the devel/swig update a week ago. I Haven't seen them in the bulk build i ran with the swig update diff.. Hm, in fact i hadnt seen those failures because for some reason dpb didnt try building those pkgpaths for reasons unknown to me. Yay dpb. Landry
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 03:16:16PM +, Christian Weisgerber wrote:
Stuart Henderson st...@openbsd.org wrote:
lang/nhc98: segfaults in build
NOT_FOR_ARCHS= ${LP64_ARCHS} powerpc
BROKEN-hppa=Segfault during build since the PIE switch
Do we need this for bootstrapping or reference purposes or can we
just remove it?
lang/petite-chez: undefined reference to `__guard'
ONLY_FOR_ARCHS =i386
Hmm, FreeBSD has a port of 8.4 that at least adds amd64.
The license of Petite Chez is weird and the port is very outdated. We
have better scheme interpreters/compilers like gambit, chicken or
racket. So, ok juanfra@ if someone wants delete the port :)
Frankly, I would like to kill the remaining !LP64 and i386-only
ports. (Excluding such things as tpwireless.)
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: i386 bulk build failures
On Thu, Jan 02, 2014 at 11:19:57PM +0100, Landry Breuil wrote: I Haven't seen them in the bulk build i ran with the swig update diff.. Hm, in fact i hadnt seen those failures because for some reason dpb didnt try building those pkgpaths for reasons unknown to me. Yay dpb. Surprisingly enough, it tries to build them here (amd64, like opi). You probably have something broken on your side. Wouldn't be the first time. As for reasons unknown to you, hey, look at the logs, check your patches. Figure out what you're doing different...
i386 bulk build failures
Quick summary of the failures in the last i386 bulk build. Java ports are now broken on i386 as a result of JDK problems. www/chromium,proprietary: 'chrome/common/extensions/api/runtime.h' file not found - this is possibly the missing interdependency that espie just fixed. Following are PIE-related, in some cases use of -fomit-frame-pointer for i386 may help, others will need more. devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' emulators/dosbox: PIC register '%ebx' clobbered in 'asm' emulators/mupen64plus/core: now uses PIC #ifdef in src/r4300/x86/rjump.c:104 which needs newer GCC (about to send diff for this). emulators/openmsx: out of reg's emulators/xnp2: PIC register 'ebx' clobbered in 'asm' games/eduke32: out of reg's games/megaglest/base: out of reg's games/openarena: out of reg's graphics/cqcam: PIC register 'bx' clobbered in 'asm' graphics/rawstudio: out of reg's multimedia/avidemux: out of reg's sysutils/grub: GRUB requires a working absolute objcopy x11/mplayer: out of reg's x11/xdesktopwaves: PIC register 'ebx' clobbered in 'asm' Not sure about cause yet, some may be PIE-related too: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' lang/gprolog: segfault when running gplc -c --fast-math fd2c.pl lang/nhc98: segfaults in build lang/petite-chez: undefined reference to `__guard' mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. This is with the committed PIE changes only, there is a diff around to enable PIE in ports compilers too, which may expose further problems.
Re: i386 bulk build failures
On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: Quick summary of the failures in the last i386 bulk build. Java ports are now broken on i386 as a result of JDK problems. www/chromium,proprietary: 'chrome/common/extensions/api/runtime.h' file not found - this is possibly the missing interdependency that espie just fixed. Yes it is.
i386 bulk build failures 2012-03-27
Between lingering thread issues, an X11 update, and the GNOME churn, there are a few build errors: These suffer an #error only glib.h can be included directly: x11/hs-gtk x11/mono-gtk2 These run afoul of a deprecation warning in Xlib.h: x11/icewm x11/sclock For icewm, I'm not sure if some #include is missing or if the Xlib.h construct doesn't work in C++. For sclock, we could simply kill the -Werror, but upstream has also disappeared, so I've asked the maintainer what to do with the port. No idea what's wrong with those as there are no error messages: sysutils/heartbeat devel/hs-MissingH devel/hs-regex-pcre-builtin Then we have the ports that spuriously fail to build: lang/mono www/icedtea-web editors/xemacs21/stable Mono is really bad. I had to restart it several times before a build finished. Icedtea sometimes fails in configure... checking if sun.security.x509.X500Name is available... no ... because java crashes. XEmacs occasionally gets stuck in an infinite loop during the build, but this has been happening for years. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures 2012-03-27
On Wed, Mar 28, 2012 at 10:31:02PM +0200, Christian Weisgerber wrote: Between lingering thread issues, an X11 update, and the GNOME churn, there are a few build errors: These suffer an #error only glib.h can be included directly: x11/hs-gtk x11/mono-gtk2 Known but I am not able to build either ghc nor mono -- Antoine
Re: i386 bulk build failures 2012-03-27
Antoine Jacoutot: These suffer an #error only glib.h can be included directly: x11/hs-gtk x11/mono-gtk2 Known but I am not able to build either ghc nor mono The offending parts are #include glib.h #include glib/gthread.h and #include glib/glist.h respectively. These should just be #include glib.h, right? I mean, that's what the #error says. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures 2012-03-27
On Wed, Mar 28, 2012 at 10:48:31PM +0200, Christian Weisgerber wrote: Antoine Jacoutot: These suffer an #error only glib.h can be included directly: x11/hs-gtk x11/mono-gtk2 Known but I am not able to build either ghc nor mono The offending parts are #include glib.h #include glib/gthread.h and #include glib/glist.h respectively. These should just be #include glib.h, right? I mean, that's what the #error says. Yup, that's all that is needed. I didn't fix these because I wanted to be able to build them, but please go ahead. -- Antoine
i386 bulk build failures
Here's the fallout from the first post-4.9 package snapshot build on i386: graphics/enblend-enfuse enfuse.info not built graphics/pdfmod cannot convert type misc/p5-Spreadsheet-ParseExcel old version 0.2603 0.58 sysutils/ruby-rails-app-installer also failed, but that port has already been removed. -- Christian naddy Weisgerber na...@mips.inka.de
Re: i386 bulk build failures
On Fri, 18 Mar 2011, Christian Weisgerber wrote: Here's the fallout from the first post-4.9 package snapshot build on i386: graphics/enblend-enfuse enfuse.info not built graphics/pdfmod cannot convert type I fixed pdfmod this morning. -- Antoine
