Re: Ports with hardcoded "gcc", "g++"
Updated list, 2017-03-08: lang/jruby lang/nim x11/p5-Wx -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
Updated list, 2017-03-05: devel/boost java/jna lang/jruby lang/nim net/pidgin x11/p5-Wx -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
Updated list, 2017-03-04: devel/boost devel/jdk/1.7 emulators/virtualjaguar graphics/ipe lang/nim misc/rocrail net/pidgin productivity/wyrd x11/p5-Wx -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
On Thu, Mar 02, 2017 at 01:11:05PM +, Christian Weisgerber wrote: > Updated list: > > archivers/hs-zlib Matthias Kilian> databases/hs-postgresql-libpq David Schaefer > devel/boost Brad Smith > devel/cil The OpenBSD ports mailing-list > devel/hs-bytestring-mmap Matthias Kilian > devel/hs-hinotify The OpenBSD ports mailing-list > devel/hs-lifted-baseMatthias Kilian > devel/hs-networkMatthias Kilian > devel/hs-old-time Matthias Kilian > devel/hs-primitive Jim Razmus II > devel/hs-readline Matthias Kilian > devel/hs-regex-posixMatthias Kilian > devel/hs-unix-compatJim Razmus II > devel/jdk/1.7 Kurt Miller > devel/ocaml-curses The OpenBSD ports mailing-list > devel/py-sipThe OpenBSD ports mailing-list > devel/radare2/main Edd Barrett > games/ioquake3 Aaron Bieber Fix committed for ioquake3! > games/tome4 Solene Rapenne > games/wordwarvi Pascal Stumpf > graphics/birdfont Jasper Lievisse Adriaanse > graphics/hs-OpenGLRaw Matthias Kilian > lang/nimThe OpenBSD ports mailing-list > lang/squeak/vm Marc Espie > misc/rocrailSebastian Reitenbach > net/clogThe OpenBSD ports mailing-list > net/hs-curl David Schaefer > net/hs-network-info David Schaefer > net/olsrd Martin Reindl > net/pidgin Brad Smith > productivity/wyrd Okan Demirmen > security/hs-skein The OpenBSD ports mailing-list > textproc/hs-libxml-sax David Coppa > textproc/pilot_makedoc The OpenBSD ports mailing-list > www/phantomjs Francisco de Borja Lopez Rio > x11/hs-X11 Matthias Kilian > x11/p5-Wx The OpenBSD ports mailing-list > x11/qt3 Marc Espie > x11/qt4 Marc Espie > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: Ports with hardcoded "gcc", "g++"
Solène Rapennewrites: > Le 2017-02-26 16:00, Christian Weisgerber a écrit : >> Here is a first batch of ports that fail to build without "gcc" or >> "g++" being present. More will come to light eventually. At the >> moment, failing dependencies prevent about a third of the ports >> tree from being built. >> >> devel/premake4 > > hello > > I see that devel/premake4 has been fixed. > > Sadly, premake4 has gcc hardcoded when invocated. premake5 > seems to have a way to choose between gcc or clang but that's still > not honoring CC variable and I'm not sure that current port > (games/tome4) needing premake4 builds with premake5. Yeah, premake could be patched to stop hardcoding gcc, and perhaps also to respect CC. I've fixed the few hardcoded gcc calls that prevented tome4 to build, however tome4 still uses gcc at build time, this is possible due to the symlinks set up by the gcc4 module. I have added a comment about this. # The build system hardcodes the use of the "gcc" command MODULES = gcc4 MODGCC4_ARCHS = * BTW, is a recent gcc actually required to build this? tome4 seems to build fine with /usr/bin/gcc from base. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")
On Thu, Mar 02, 2017 at 10:03:29PM +0100, Karel Gardas wrote: > On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian> wrote: > > Also, I've no idea wether --with-clang=${CC} will work after the > > switch to clang. On the other hand, the diff is just a workaround, > > > +MODGHC_SETUP_CONF_ARGS += --with-gcc=${CC} --with-clang=${CC} > > > Hi Kili, > > I'm curious why this is there at all, I mean --with-clang=${CC} -- if > I understand policy, then i386/amd64 are not going to be migrated to > clang anytime soon and clang is default only for arm64 (new port which > is not supported by in tree gcc) where ghc does not exist yet. So my > curiosity and question why to bother with it at all? We're just shaking the ports tree, seeing what bugs fall out. Seriously, removing all traces of unjustified hardcoded gccs is good. There are probably going to still be ports where things may want to know. In any case, having configury that explicitly says "hey this is not called gcc, so it's not gcc" is... simple-minded. That's just your usual ports tree stuff: a sweep of 9000+ ports, weeding out the trivial stuff, so that we can actually spend a few hours on the remaining stuff. Cabal is somewhat annoying, because it takes out a large portion of the tree, so it's somewhat important to take care of it. So does boost, for that matter...
Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")
On Thu, Mar 2, 2017 at 11:35 PM, Matthias Kilianwrote: > On Thu, Mar 02, 2017 at 09:23:25PM +0100, Matthias Kilian wrote: >> Running an update bulk build with the diff below now for ghc-7.10.3, >> to see wether it helps... however, all the hs-ports in my tree are still >> updated for ghc-8.0.1, so I've no idea wether I'll see anything useful. >> >> Also, I've no idea wether --with-clang=${CC} will work after the >> switch to clang. > > Sigh... cabal ports don't't support --with-clang (in contrast to > ghc, if I didn't misread its configure and build magic). New diff > below (and I've already failures from pkg_create, which is a *good* > sign, because it means my (ahead of head) hs-ports at least don't > fail to build). > > > Index: ghc.port.mk > === > RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v > retrieving revision 1.38 > diff -u -p -r1.38 ghc.port.mk > --- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38 > +++ ghc.port.mk 2 Mar 2017 22:23:03 - > @@ -56,7 +56,7 @@ DIST_SUBDIR ?=ghc > . if ${MODGHC_BUILD:L:Mcabal} > MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs > MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup > -MODGHC_SETUP_CONF_ARGS ?= > +MODGHC_SETUP_CONF_ARGS += --with-gcc=${CC} > MODGHC_SETUP_CONF_ENV ?= > > . if !${MODGHC_BUILD:L:Mnort} > ok dcoppa@ Ciao! David
Re: Ports with hardcoded "gcc", "g++"
On Thu, Mar 02, 2017 at 08:44:39PM +0100, Christian Weisgerber wrote: > Juan Francisco Cantero Hurtado: > > > > ===> Building for nim-0.16.0p0 > > > cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" > > > LINKER="gcc" CFLA > > > GS="-O2 -pipe " sh build.sh > > > gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c > > > c_code/3_2/compiler_nim.c -o c > > > _code/3_2/compiler_nim.o > > > build.sh[7343]: gcc: not found > > > *** Error 127 in . (Makefile:36 'do-build') > > > > Add amd64 to CLANG_ARCHS in arch-defines.mk and the port will build > > fine. > > Why should I do that? > It isn't supposed to call "gcc" on gcc archs either! Sorry but I don't have more ideas. I've been trying to create a patch without to "hardcode" a compiler this afternoon and I failed. Even if someone makes a patch to honor CC, it would break nim for clang architectures. If you remove the "gcc" commands from nim to honor CC during the build on every architecture, then the clang architectures would have a nim compiler which calls clang when you use "nim c -cc:gcc". That's why I used the CLANG_ARCHS conditional and the "-cc" option in the previous patch. We also can remove the nim port and to wait until someone steps up as maintainer :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")
On Thu, Mar 02, 2017 at 09:23:25PM +0100, Matthias Kilian wrote: > Running an update bulk build with the diff below now for ghc-7.10.3, > to see wether it helps... however, all the hs-ports in my tree are still > updated for ghc-8.0.1, so I've no idea wether I'll see anything useful. > > Also, I've no idea wether --with-clang=${CC} will work after the > switch to clang. Sigh... cabal ports don't't support --with-clang (in contrast to ghc, if I didn't misread its configure and build magic). New diff below (and I've already failures from pkg_create, which is a *good* sign, because it means my (ahead of head) hs-ports at least don't fail to build). Index: ghc.port.mk === RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v retrieving revision 1.38 diff -u -p -r1.38 ghc.port.mk --- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38 +++ ghc.port.mk 2 Mar 2017 22:23:03 - @@ -56,7 +56,7 @@ DIST_SUBDIR ?=ghc . if ${MODGHC_BUILD:L:Mcabal} MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup -MODGHC_SETUP_CONF_ARGS ?= +MODGHC_SETUP_CONF_ARGS += --with-gcc=${CC} MODGHC_SETUP_CONF_ENV ?= . if !${MODGHC_BUILD:L:Mnort}
Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")
On 2017/03/02 22:03, Karel Gardas wrote: > On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian> wrote: > > Also, I've no idea wether --with-clang=${CC} will work after the > > switch to clang. On the other hand, the diff is just a workaround, > > > +MODGHC_SETUP_CONF_ARGS += --with-gcc=${CC} --with-clang=${CC} > > > Hi Kili, > > I'm curious why this is there at all, I mean --with-clang=${CC} -- if > I understand policy, then i386/amd64 are not going to be migrated to > clang anytime soon and clang is default only for arm64 (new port which > is not supported by in tree gcc) where ghc does not exist yet. So my > curiosity and question why to bother with it at all? One of the prerequisites for switching other architectures is that it won't cause too much damage to the ports tree..
Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")
On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilianwrote: > Also, I've no idea wether --with-clang=${CC} will work after the > switch to clang. On the other hand, the diff is just a workaround, > +MODGHC_SETUP_CONF_ARGS += --with-gcc=${CC} --with-clang=${CC} Hi Kili, I'm curious why this is there at all, I mean --with-clang=${CC} -- if I understand policy, then i386/amd64 are not going to be migrated to clang anytime soon and clang is default only for arm64 (new port which is not supported by in tree gcc) where ghc does not exist yet. So my curiosity and question why to bother with it at all? Thanks, Karel
ghc.port.mk (was: Ports with hardcoded "gcc", "g++")
Hi, On Thu, Mar 02, 2017 at 01:11:05PM +, Christian Weisgerber wrote: > Updated list: > > archivers/hs-zlib Matthias Kilian> databases/hs-postgresql-libpq David Schaefer [...] Running an update bulk build with the diff below now for ghc-7.10.3, to see wether it helps... however, all the hs-ports in my tree are still updated for ghc-8.0.1, so I've no idea wether I'll see anything useful. Also, I've no idea wether --with-clang=${CC} will work after the switch to clang. On the other hand, the diff is just a workaround, the real problem are wrong checks in configure scripts and bugs/thinkos in the ssource code of libraries/Cabal. Ciao, Kili Index: ghc.port.mk === RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v retrieving revision 1.38 diff -u -p -r1.38 ghc.port.mk --- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38 +++ ghc.port.mk 2 Mar 2017 20:16:25 - @@ -56,7 +56,7 @@ DIST_SUBDIR ?=ghc . if ${MODGHC_BUILD:L:Mcabal} MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup -MODGHC_SETUP_CONF_ARGS ?= +MODGHC_SETUP_CONF_ARGS += --with-gcc=${CC} --with-clang=${CC} MODGHC_SETUP_CONF_ENV ?= . if !${MODGHC_BUILD:L:Mnort}
Re: Ports with hardcoded "gcc", "g++"
Juan Francisco Cantero Hurtado: > > ===> Building for nim-0.16.0p0 > > cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" LINKER="gcc" > > CFLA > > GS="-O2 -pipe " sh build.sh > > gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c c_code/3_2/compiler_nim.c > > -o c > > _code/3_2/compiler_nim.o > > build.sh[7343]: gcc: not found > > *** Error 127 in . (Makefile:36 'do-build') > > Add amd64 to CLANG_ARCHS in arch-defines.mk and the port will build > fine. Why should I do that? It isn't supposed to call "gcc" on gcc archs either! -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
On Thu, Mar 02, 2017 at 04:33:40PM +0100, Christian Weisgerber wrote: > Juan Francisco Cantero Hurtado: > > > > I changed the variable to NIM_CC. OK? > > > > And now with "elif" -> "else" fixed. > > There is still confusion about CC and NIM_CC: > > ===> Building for nim-0.16.0p0 > cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" LINKER="gcc" > CFLA > GS="-O2 -pipe " sh build.sh > gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c c_code/3_2/compiler_nim.c > -o c > _code/3_2/compiler_nim.o > build.sh[7343]: gcc: not found > *** Error 127 in . (Makefile:36 'do-build') Add amd64 to CLANG_ARCHS in arch-defines.mk and the port will build fine. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Ports with hardcoded "gcc", "g++"
Le 2017-02-26 16:00, Christian Weisgerber a écrit : Here is a first batch of ports that fail to build without "gcc" or "g++" being present. More will come to light eventually. At the moment, failing dependencies prevent about a third of the ports tree from being built. devel/premake4 hello I see that devel/premake4 has been fixed. Sadly, premake4 has gcc hardcoded when invocated. premake5 seems to have a way to choose between gcc or clang but that's still not honoring CC variable and I'm not sure that current port (games/tome4) needing premake4 builds with premake5. regards
Re: Ports with hardcoded "gcc", "g++"
Juan Francisco Cantero Hurtado: > > I changed the variable to NIM_CC. OK? > > And now with "elif" -> "else" fixed. There is still confusion about CC and NIM_CC: ===> Building for nim-0.16.0p0 cd /usr/obj/nim-0.16.0/nim-0.16.0 && /usr/bin/env -i CC="gcc" LINKER="gcc" CFLA GS="-O2 -pipe " sh build.sh gcc -O2 -pipe -w -fno-strict-aliasing -Ic_code -c c_code/3_2/compiler_nim.c -o c _code/3_2/compiler_nim.o build.sh[7343]: gcc: not found *** Error 127 in . (Makefile:36 'do-build') -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
Updated list: archivers/hs-zlib Matthias Kiliandatabases/hs-postgresql-libpq David Schaefer devel/boost Brad Smith devel/cil The OpenBSD ports mailing-list devel/hs-bytestring-mmap Matthias Kilian devel/hs-hinotify The OpenBSD ports mailing-list devel/hs-lifted-baseMatthias Kilian devel/hs-networkMatthias Kilian devel/hs-old-time Matthias Kilian devel/hs-primitive Jim Razmus II devel/hs-readline Matthias Kilian devel/hs-regex-posixMatthias Kilian devel/hs-unix-compatJim Razmus II devel/jdk/1.7 Kurt Miller devel/ocaml-curses The OpenBSD ports mailing-list devel/py-sipThe OpenBSD ports mailing-list devel/radare2/main Edd Barrett games/ioquake3 Aaron Bieber games/tome4 Solene Rapenne games/wordwarvi Pascal Stumpf graphics/birdfont Jasper Lievisse Adriaanse graphics/hs-OpenGLRaw Matthias Kilian lang/nimThe OpenBSD ports mailing-list lang/squeak/vm Marc Espie misc/rocrailSebastian Reitenbach net/clogThe OpenBSD ports mailing-list net/hs-curl David Schaefer net/hs-network-info David Schaefer net/olsrd Martin Reindl net/pidgin Brad Smith productivity/wyrd Okan Demirmen security/hs-skein The OpenBSD ports mailing-list textproc/hs-libxml-sax David Coppa textproc/pilot_makedoc The OpenBSD ports mailing-list www/phantomjs Francisco de Borja Lopez Rio x11/hs-X11 Matthias Kilian x11/p5-Wx The OpenBSD ports mailing-list x11/qt3 Marc Espie x11/qt4 Marc Espie -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
On Thu, Mar 02, 2017 at 12:46:58AM +0100, Juan Francisco Cantero Hurtado wrote: > On Wed, Mar 01, 2017 at 11:36:52PM +0100, Juan Francisco Cantero Hurtado > wrote: > > On Wed, Mar 01, 2017 at 11:09:03PM +0100, Christian Weisgerber wrote: > > > Juan Francisco Cantero Hurtado: > > > > > > > They have a simple option to change the compilers but we need a variable > > > > with the realname of the compiler, i.e. clang or gcc. > > > > > > > > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c > > > > -cc:egcc". All of them are the name of the profile, not the compiler > > > > executable. > > > > > > > > Here is the patch. It includes some adittional changes. If someone has > > > > an better idea for the conditional... I'm listening :) > > > > > > CLANG_ARCHS was added incompletely, so you need arch-defines.mk > > > r1.32 for that: > > > > > > .include > > > > > > # CC is always "cc". We need the real name. > > > .if ${PROPERTIES:Mclang} > > > CC = clang > > > .else > > > CC = gcc > > > .endif > > > > > > BTW, I think using CC for a variable with different semantics is a > > > bad idea. Pick a different name, please. > > > > Thanks. How about "COMPILER" or "C_COMP"? > > I changed the variable to NIM_CC. OK? And now with "elif" -> "else" fixed. Index: Makefile === RCS file: /cvs/ports/lang/nim/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile9 Jan 2017 10:32:33 - 1.6 +++ Makefile1 Mar 2017 23:41:07 - @@ -5,6 +5,7 @@ ONLY_FOR_ARCHS =i386 amd64 COMMENT = statically typed, imperative programming language VERSION = 0.16.0 +REVISION = 0 DISTNAME = nim-${VERSION} EXTRACT_SUFX = .tar.xz @@ -19,23 +20,28 @@ PERMIT_PACKAGE_CDROM = Yes WANTLIB = c m +SUBST_VARS += NIM_CC + post-patch: mkdir -p ${WRKSRC}/nimcache-port mkdir -p ${WRKSRC}/nimcache-port-test perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \ ${WRKSRC}/koch.nim + ${SUBST_CMD} ${WRKSRC}/koch.nim ${WRKSRC}/tests/testament/tester.nim \ + ${WRKSRC}/config/nim.cfg do-build: - cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \ + cd ${WRKSRC} && ${SETENV} CC="${NIM_CC}" LINKER="${NIM_CC}" \ CFLAGS="${CFLAGS}" sh build.sh # slow machines can get a head of themselves and fail to link - cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \ - --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \ - --listCmd --putenv:"PATH=${PATH}" koch - cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \ - --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \ - --listCmd --putenv:"PATH=${PATH}" + cd ${WRKSRC} && bin/nim c -d:release --cc:${NIM_CC} --parallelBuild:1 \ + --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \ + --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" \ + koch + cd ${WRKSRC} && ./koch boot -d:release --cc:${NIM_CC} --parallelBuild:1 \ + --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \ + --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" do-install: ${INSTALL_PROGRAM_DIR} ${PREFIX}/bin @@ -49,9 +55,17 @@ do-install: ${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim do-test: - cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \ - --parallelBuild:1 --listFullPaths --listCmd \ - --nimcache:"${WRKSRC}/nimcache-port-test" \ - --putenv:"PATH=${PATH}" + cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --threads:on \ + --cc:${NIM_CC} --parallelBuild:1 --listFullPaths --listCmd \ + --passL:"-pthread -Wl,-rpath=.:/usr/local/lib:${WRKSRC}/nimcache-port-test/" \ + --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" + +.include + +.if ${PROPERTIES:Mclang} +NIM_CC = clang +.else +NIM_CC = gcc +.endif .include Index: patches/patch-config_nim_cfg === RCS file: /cvs/ports/lang/nim/patches/patch-config_nim_cfg,v retrieving revision 1.3 diff -u -p -r1.3 patch-config_nim_cfg --- patches/patch-config_nim_cfg9 Jan 2017 10:32:33 - 1.3 +++ patches/patch-config_nim_cfg1 Mar 2017 23:41:07 - @@ -1,6 +1,15 @@ $OpenBSD: patch-config_nim_cfg,v 1.3 2017/01/09 10:32:33 juanfra Exp $ --- config/nim.cfg.origSun Jan 8 21:33:42 2017 -+++ config/nim.cfg Mon Jan 9 02:28:32 2017 config/nim.cfg Wed Mar 1 00:00:37 2017 +@@ -8,7 +8,7 @@ + # Environment variables can be accessed like so: + #
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 01, 2017 at 11:36:52PM +0100, Juan Francisco Cantero Hurtado wrote: > On Wed, Mar 01, 2017 at 11:09:03PM +0100, Christian Weisgerber wrote: > > Juan Francisco Cantero Hurtado: > > > > > They have a simple option to change the compilers but we need a variable > > > with the realname of the compiler, i.e. clang or gcc. > > > > > > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c > > > -cc:egcc". All of them are the name of the profile, not the compiler > > > executable. > > > > > > Here is the patch. It includes some adittional changes. If someone has > > > an better idea for the conditional... I'm listening :) > > > > CLANG_ARCHS was added incompletely, so you need arch-defines.mk > > r1.32 for that: > > > > .include > > > > # CC is always "cc". We need the real name. > > .if ${PROPERTIES:Mclang} > > CC = clang > > .else > > CC = gcc > > .endif > > > > BTW, I think using CC for a variable with different semantics is a > > bad idea. Pick a different name, please. > > Thanks. How about "COMPILER" or "C_COMP"? I changed the variable to NIM_CC. OK? Index: Makefile === RCS file: /cvs/ports/lang/nim/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile9 Jan 2017 10:32:33 - 1.6 +++ Makefile1 Mar 2017 23:41:07 - @@ -5,6 +5,7 @@ ONLY_FOR_ARCHS =i386 amd64 COMMENT = statically typed, imperative programming language VERSION = 0.16.0 +REVISION = 0 DISTNAME = nim-${VERSION} EXTRACT_SUFX = .tar.xz @@ -19,23 +20,28 @@ PERMIT_PACKAGE_CDROM = Yes WANTLIB = c m +SUBST_VARS += NIM_CC + post-patch: mkdir -p ${WRKSRC}/nimcache-port mkdir -p ${WRKSRC}/nimcache-port-test perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \ ${WRKSRC}/koch.nim + ${SUBST_CMD} ${WRKSRC}/koch.nim ${WRKSRC}/tests/testament/tester.nim \ + ${WRKSRC}/config/nim.cfg do-build: - cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \ + cd ${WRKSRC} && ${SETENV} CC="${NIM_CC}" LINKER="${NIM_CC}" \ CFLAGS="${CFLAGS}" sh build.sh # slow machines can get a head of themselves and fail to link - cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \ - --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \ - --listCmd --putenv:"PATH=${PATH}" koch - cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \ - --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \ - --listCmd --putenv:"PATH=${PATH}" + cd ${WRKSRC} && bin/nim c -d:release --cc:${NIM_CC} --parallelBuild:1 \ + --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \ + --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" \ + koch + cd ${WRKSRC} && ./koch boot -d:release --cc:${NIM_CC} --parallelBuild:1 \ + --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \ + --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" do-install: ${INSTALL_PROGRAM_DIR} ${PREFIX}/bin @@ -49,9 +55,17 @@ do-install: ${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim do-test: - cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \ - --parallelBuild:1 --listFullPaths --listCmd \ - --nimcache:"${WRKSRC}/nimcache-port-test" \ - --putenv:"PATH=${PATH}" + cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --threads:on \ + --cc:${NIM_CC} --parallelBuild:1 --listFullPaths --listCmd \ + --passL:"-pthread -Wl,-rpath=.:/usr/local/lib:${WRKSRC}/nimcache-port-test/" \ + --putenv:"PATH=${PATH} CC=${NIM_CC} LINKER=${NIM_CC}" + +.include + +.if ${PROPERTIES:Mclang} +NIM_CC = clang +.elif +NIM_CC = gcc +.endif .include Index: patches/patch-config_nim_cfg === RCS file: /cvs/ports/lang/nim/patches/patch-config_nim_cfg,v retrieving revision 1.3 diff -u -p -r1.3 patch-config_nim_cfg --- patches/patch-config_nim_cfg9 Jan 2017 10:32:33 - 1.3 +++ patches/patch-config_nim_cfg1 Mar 2017 23:41:07 - @@ -1,6 +1,15 @@ $OpenBSD: patch-config_nim_cfg,v 1.3 2017/01/09 10:32:33 juanfra Exp $ --- config/nim.cfg.origSun Jan 8 21:33:42 2017 -+++ config/nim.cfg Mon Jan 9 02:28:32 2017 config/nim.cfg Wed Mar 1 00:00:37 2017 +@@ -8,7 +8,7 @@ + # Environment variables can be accessed like so: + # gcc.path %= "$CC_PATH" + +-cc = gcc ++cc = ${NIM_CC} + + # additional options always passed to the compiler: + --parallel_build: "0" # 0 to auto-detect number of processors @@ -76,7
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 01, 2017 at 11:09:03PM +0100, Christian Weisgerber wrote: > Juan Francisco Cantero Hurtado: > > > They have a simple option to change the compilers but we need a variable > > with the realname of the compiler, i.e. clang or gcc. > > > > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c > > -cc:egcc". All of them are the name of the profile, not the compiler > > executable. > > > > Here is the patch. It includes some adittional changes. If someone has > > an better idea for the conditional... I'm listening :) > > CLANG_ARCHS was added incompletely, so you need arch-defines.mk > r1.32 for that: > > .include > > # CC is always "cc". We need the real name. > .if ${PROPERTIES:Mclang} > CC = clang > .else > CC = gcc > .endif > > BTW, I think using CC for a variable with different semantics is a > bad idea. Pick a different name, please. Thanks. How about "COMPILER" or "C_COMP"? -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 01, 2017 at 08:41:17PM +, Stuart Henderson wrote: > On 2017/03/01 21:15, Juan Francisco Cantero Hurtado wrote: > > On Wed, Mar 01, 2017 at 05:45:32PM +, Stuart Henderson wrote: > > > On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote: > > > > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero > > > > Hurtado wrote: > > > > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote: > > > > > > The fixes that have been committed have unlocked additional parts > > > > > > of the ports tree, revealing new build failures. Here is an updated > > > > > > list. I've added the MAINTAINERs. > > > > > > > > > > > > lang/nimThe OpenBSD ports mailing-list > > > > > >> > > > > > > > > > I've a patch for nim from two or three days ago. It builds the package > > > > > but I don't find where is the gcc command in the tests and I don't > > > > > want > > > > > commit the changes without to run first the tests. > > > > > > > > Everything is working now but I need help with something. Nim uses a > > > > kind of compiler profiles, so we can't just add "${CC}" to the build, we > > > > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using > > > > an if/else conditional with MACHINE_ARCH to define the compiler but I > > > > would like to use something like "if CLANG_ARCHS contains > > > > MACHINE_ARCH...". I don't know how to write that. Any idea?. > > > > > > > > -- > > > > Juan Francisco Cantero Hurtado http://juanfra.info > > > > > > > > > > Ports should honour CC/CXX. Can you sed these into wherever the > > > compiler profile is defined? > > > > No, because ${CC} is always "cc", not "gcc" or "clang". > > ${CC} is not always "cc", it can be set to something else. For example > if I do "scan-build make", it is /usr/local/bin/../libexec/ccc-analyzer. > It might be something else if I want to use distcc, etc. I know. I meant "by default". I used "make CC=clang" to work in the port. Anyway, I need a final solution for the port. If people wants to use "mycompiler" to build nim, then they can create a new entry for the compiler in the nim config and to run make with "CC=mycompiler". e.g. jturner@ added the entry for "egcc" long time ago. Meanwhile, I could commit the port with the conditional commented: #.if ${MACHINE_ARCH} == "amd64" #CC = clang #.elif CC = gcc #.endif With the changes, "CC=cc" will not work anymore. In fact, nim never used "cc" as its compiler. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Ports with hardcoded "gcc", "g++"
Juan Francisco Cantero Hurtado: > They have a simple option to change the compilers but we need a variable > with the realname of the compiler, i.e. clang or gcc. > > You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c > -cc:egcc". All of them are the name of the profile, not the compiler > executable. > > Here is the patch. It includes some adittional changes. If someone has > an better idea for the conditional... I'm listening :) CLANG_ARCHS was added incompletely, so you need arch-defines.mk r1.32 for that: .include # CC is always "cc". We need the real name. .if ${PROPERTIES:Mclang} CC = clang .else CC = gcc .endif BTW, I think using CC for a variable with different semantics is a bad idea. Pick a different name, please. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 1, 2017, at 17:47, Amit Kulkarni wrote: > I meant to say the .a file is missing for libQtWebkit > > Thanks > Found the cause and fixed it. Attached patch makes it build correctly without g++/gcc. Thanks again Stuart and Amit for the hints. Frank Index: Makefile === RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v retrieving revision 1.12 diff -u -p -r1.12 Makefile --- Makefile 13 Sep 2016 18:52:06 - 1.12 +++ Makefile 1 Mar 2017 20:06:14 - @@ -39,7 +39,9 @@ LIB_DEPENDS = converters/libiconv \ USE_GMAKE = Yes MAKE_FLAGS = LIBwkhtmltox_VERSION=${LIBwkhtmltox_VERSION} -MAKE_ENV += WRKBUILD=${WRKBUILD} +MAKE_ENV += WRKBUILD=${WRKBUILD} \ + PORTS_CC="${CC}" PORTS_CXX="${CXX}" +CONFIGURE_ENV = PORTS_CC="${CC}" PORTS_CXX="${CXX}" FAKE_FLAGS = INSTALL_ROOT=${WRKINST}${TRUEPREFIX} SEPARATE_BUILD = Yes @@ -51,7 +53,7 @@ pre-patch: cd ${WRKDIR}/${DISTNAME} && mv ../qt-${QT_COMMIT} qt do-configure: - mkdir ${WRKBUILD}/qt + mkdir -p ${WRKBUILD}/qt # qt config options taken from scripts/build.py cd ${WRKBUILD}/qt && \ env -i ${CONFIGURE_ENV} ${WRKSRC}/qt/configure \ Index: patches/patch-qt_configure === RCS file: patches/patch-qt_configure diff -N patches/patch-qt_configure --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-qt_configure 1 Mar 2017 20:06:14 - @@ -0,0 +1,12 @@ +$OpenBSD$ +--- qt/configure.orig Wed Mar 1 20:53:04 2017 qt/configure Wed Mar 1 20:53:19 2017 +@@ -3411,7 +3411,7 @@ else + CFG_FRAMEWORK=no + fi + +-QMAKE_CONF_COMPILER=`getXQMakeConf QMAKE_CXX` ++QMAKE_CONF_COMPILER="${PORTS_CXX}" + TEST_COMPILER="$CXX" + + [ -z "$TEST_COMPILER" ] && TEST_COMPILER=$QMAKE_CONF_COMPILER Index: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf === RCS file: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf diff -N patches/patch-qt_mkspecs_openbsd-g++_qmake_conf --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-qt_mkspecs_openbsd-g++_qmake_conf 1 Mar 2017 20:06:14 - @@ -0,0 +1,36 @@ +$OpenBSD$ +--- qt/mkspecs/openbsd-g++/qmake.conf.orig Tue May 10 09:19:52 2016 qt/mkspecs/openbsd-g++/qmake.conf Wed Mar 1 12:07:44 2017 +@@ -8,7 +8,7 @@ TEMPLATE = app + CONFIG += qt warn_on release link_prl gdb_dwarf_index + QT += core gui + +-QMAKE_CC = gcc ++QMAKE_CC = ${PORTS_CC} + QMAKE_LEX = flex + QMAKE_LEXFLAGS = + QMAKE_YACC = yacc +@@ -24,7 +24,7 @@ QMAKE_CFLAGS_STATIC_LIB = $$QMAKE_CFLAGS_SHLIB + QMAKE_CFLAGS_YACC = -Wno-unused -Wno-parentheses + QMAKE_CFLAGS_THREAD = -pthread + +-QMAKE_CXX = g++ ++QMAKE_CXX = ${PORTS_CXX} + QMAKE_CXXFLAGS = $$QMAKE_CFLAGS + QMAKE_CXXFLAGS_DEPS = $$QMAKE_CFLAGS_DEPS + QMAKE_CXXFLAGS_WARN_ON = $$QMAKE_CFLAGS_WARN_ON +@@ -45,10 +45,10 @@ QMAKE_LIBDIR_QT = $$[QT_INSTALL_LIBS] + QMAKE_INCDIR_OPENGL = /usr/X11R6/include + QMAKE_LIBDIR_OPENGL = /usr/X11R6/lib + +-QMAKE_LINK = g++ +-QMAKE_LINK_SHLIB = g++ +-QMAKE_LINK_C = gcc +-QMAKE_LINK_C_SHLIB = gcc ++QMAKE_LINK = $$QMAKE_CXX ++QMAKE_LINK_SHLIB = $$QMAKE_CXX ++QMAKE_LINK_C = $$QMAKE_CC ++QMAKE_LINK_C_SHLIB = $$QMAKE_CC + QMAKE_LINK_SHLIB_CMD = $$QMAKE_LINK_SHLIB $(LFLAGS) \ + $$QMAKE_CFLAGS_SHLIB $$QMAKE_LFLAGS \ + -o $(TARGETD) $(OBJECTS) $(OBJMOC) $(LIBS)
Re: Ports with hardcoded "gcc", "g++"
On 2017/03/01 21:15, Juan Francisco Cantero Hurtado wrote: > On Wed, Mar 01, 2017 at 05:45:32PM +, Stuart Henderson wrote: > > On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote: > > > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado > > > wrote: > > > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote: > > > > > The fixes that have been committed have unlocked additional parts > > > > > of the ports tree, revealing new build failures. Here is an updated > > > > > list. I've added the MAINTAINERs. > > > > > > > > > > lang/nimThe OpenBSD ports mailing-list> > > > > > > > I've a patch for nim from two or three days ago. It builds the package > > > > but I don't find where is the gcc command in the tests and I don't want > > > > commit the changes without to run first the tests. > > > > > > Everything is working now but I need help with something. Nim uses a > > > kind of compiler profiles, so we can't just add "${CC}" to the build, we > > > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using > > > an if/else conditional with MACHINE_ARCH to define the compiler but I > > > would like to use something like "if CLANG_ARCHS contains > > > MACHINE_ARCH...". I don't know how to write that. Any idea?. > > > > > > -- > > > Juan Francisco Cantero Hurtado http://juanfra.info > > > > > > > Ports should honour CC/CXX. Can you sed these into wherever the > > compiler profile is defined? > > No, because ${CC} is always "cc", not "gcc" or "clang". ${CC} is not always "cc", it can be set to something else. For example if I do "scan-build make", it is /usr/local/bin/../libexec/ccc-analyzer. It might be something else if I want to use distcc, etc.
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 01, 2017 at 05:45:32PM +, Stuart Henderson wrote: > On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote: > > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado > > wrote: > > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote: > > > > The fixes that have been committed have unlocked additional parts > > > > of the ports tree, revealing new build failures. Here is an updated > > > > list. I've added the MAINTAINERs. > > > > > > > > lang/nimThe OpenBSD ports mailing-list> > > > > > I've a patch for nim from two or three days ago. It builds the package > > > but I don't find where is the gcc command in the tests and I don't want > > > commit the changes without to run first the tests. > > > > Everything is working now but I need help with something. Nim uses a > > kind of compiler profiles, so we can't just add "${CC}" to the build, we > > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using > > an if/else conditional with MACHINE_ARCH to define the compiler but I > > would like to use something like "if CLANG_ARCHS contains > > MACHINE_ARCH...". I don't know how to write that. Any idea?. > > > > -- > > Juan Francisco Cantero Hurtado http://juanfra.info > > > > Ports should honour CC/CXX. Can you sed these into wherever the > compiler profile is defined? No, because ${CC} is always "cc", not "gcc" or "clang". We can't use a regex blindly to modify nim because it will give us problems. Patching the code is even worse because the updates will be harder and nim hasn't a maintainer. They have a simple option to change the compilers but we need a variable with the realname of the compiler, i.e. clang or gcc. You can use "nim c -cc:clang" or "nim c -cc:gcc" (the default) or "nim c -cc:egcc". All of them are the name of the profile, not the compiler executable. Here is the patch. It includes some adittional changes. If someone has an better idea for the conditional... I'm listening :) Index: Makefile === RCS file: /cvs/ports/lang/nim/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile9 Jan 2017 10:32:33 - 1.6 +++ Makefile1 Mar 2017 19:55:21 - @@ -5,6 +5,7 @@ ONLY_FOR_ARCHS =i386 amd64 COMMENT = statically typed, imperative programming language VERSION = 0.16.0 +REVISION = 0 DISTNAME = nim-${VERSION} EXTRACT_SUFX = .tar.xz @@ -19,23 +20,28 @@ PERMIT_PACKAGE_CDROM = Yes WANTLIB = c m +SUBST_VARS += CC + post-patch: mkdir -p ${WRKSRC}/nimcache-port mkdir -p ${WRKSRC}/nimcache-port-test perl -i -pe "s#NIM_PORT_PATH#${PATH}#" ${WRKSRC}/koch.nim perl -i -pe "s#NIM_PORT_CACHE#${WRKSRC}/nimcache-port-test#" \ ${WRKSRC}/koch.nim + ${SUBST_CMD} ${WRKSRC}/koch.nim ${WRKSRC}/tests/testament/tester.nim \ + ${WRKSRC}/config/nim.cfg do-build: cd ${WRKSRC} && ${SETENV} CC="${CC}" LINKER="${CC}" \ CFLAGS="${CFLAGS}" sh build.sh # slow machines can get a head of themselves and fail to link - cd ${WRKSRC} && bin/nim c -d:release --parallelBuild:1 \ - --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \ - --listCmd --putenv:"PATH=${PATH}" koch - cd ${WRKSRC} && ./koch boot -d:release --parallelBuild:1 \ - --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths \ - --listCmd --putenv:"PATH=${PATH}" + cd ${WRKSRC} && bin/nim c -d:release --cc:${CC} --parallelBuild:1 \ + --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \ + --putenv:"PATH=${PATH} CC=${CC} LINKER=${CC}" \ + koch + cd ${WRKSRC} && ./koch boot -d:release --cc:${CC} --parallelBuild:1 \ + --nimcache:"${WRKSRC}/nimcache-port" --listFullPaths --listCmd \ + --putenv:"PATH=${PATH} CC=${CC} LINKER=${CC}" do-install: ${INSTALL_PROGRAM_DIR} ${PREFIX}/bin @@ -49,9 +55,16 @@ do-install: ${INSTALL_DATA} ${WRKSRC}/config/*.cfg ${PREFIX}/share/examples/nim do-test: - cd ${WRKSRC} && ${SETENV} ./koch test all -d:release \ - --parallelBuild:1 --listFullPaths --listCmd \ - --nimcache:"${WRKSRC}/nimcache-port-test" \ - --putenv:"PATH=${PATH}" + cd ${WRKSRC} && ${SETENV} ./koch test all -d:release --threads:on \ + --cc:${CC} --parallelBuild:1 --listFullPaths --listCmd \ + --passL:"-pthread -Wl,-rpath=.:/usr/local/lib:${WRKSRC}/nimcache-port-test/" \ + --putenv:"PATH=${PATH} CC=${CC} LINKER=${CC}" + +# CC is always "cc". We need the real name. +.if ${MACHINE_ARCH} == "amd64" +CC = clang +.elif +CC = gcc +.endif .include Index: patches/patch-config_nim_cfg
Re: Ports with hardcoded "gcc", "g++"
On 2017/03/01 17:10, Juan Francisco Cantero Hurtado wrote: > On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado > wrote: > > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote: > > > The fixes that have been committed have unlocked additional parts > > > of the ports tree, revealing new build failures. Here is an updated > > > list. I've added the MAINTAINERs. > > > > > > lang/nimThe OpenBSD ports mailing-list> > > > I've a patch for nim from two or three days ago. It builds the package > > but I don't find where is the gcc command in the tests and I don't want > > commit the changes without to run first the tests. > > Everything is working now but I need help with something. Nim uses a > kind of compiler profiles, so we can't just add "${CC}" to the build, we > need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using > an if/else conditional with MACHINE_ARCH to define the compiler but I > would like to use something like "if CLANG_ARCHS contains > MACHINE_ARCH...". I don't know how to write that. Any idea?. > > -- > Juan Francisco Cantero Hurtado http://juanfra.info > Ports should honour CC/CXX. Can you sed these into wherever the compiler profile is defined?
Re: Ports with hardcoded "gcc", "g++"
On Tue, Feb 28, 2017 at 07:11:48PM +0100, Juan Francisco Cantero Hurtado wrote: > On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote: > > The fixes that have been committed have unlocked additional parts > > of the ports tree, revealing new build failures. Here is an updated > > list. I've added the MAINTAINERs. > > > > lang/nimThe OpenBSD ports mailing-list> > I've a patch for nim from two or three days ago. It builds the package > but I don't find where is the gcc command in the tests and I don't want > commit the changes without to run first the tests. Everything is working now but I need help with something. Nim uses a kind of compiler profiles, so we can't just add "${CC}" to the build, we need to define the real compiler, i.e. gcc, egcc or clang. Now I'm using an if/else conditional with MACHINE_ARCH to define the compiler but I would like to use something like "if CLANG_ARCHS contains MACHINE_ARCH...". I don't know how to write that. Any idea?. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 1, 2017 at 10:44 AM, Amit Kulkarniwrote: > On Wed, Mar 1, 2017 at 10:10 AM, Frank Groeneveld > wrote: >> On Wed, Mar 1, 2017, at 15:14, Stuart Henderson wrote: >>> Oops, I forgot to re-run update-patches and had an old one. However >>> unfortunately >>> not enough as linking fails. >>> >> >> Thanks, that gets us a lot further indeed. The complete QT build >> finished and now only the final linking step fails indeed. >> For the interested, this is the command: >> >> c++ -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -pthread >> -shared -Wl,-soname,libwkhtmltox.so.0 -fPIC -o libwkhtmltox.so.0.0 >> loadsettings.o multipageloader.o tempfile.o converter.o websettings.o >> reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o >> tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o >> image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o >> moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o >> moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o >> moc_utilities.o moc_pdfconverter.o moc_imageconverter.o >> qrc_wkhtmltopdf.o-L/usr/local/lib >> -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib >> -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/plugins/codecs >> -lqcncodecs -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib >> -L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit >> -L/usr/X11R6/lib -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender >> -lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lQtCore -lz -lm >> -liconv >> /usr/bin/ld: cannot find -lQtWebKit >> >> Which seems weird to me, because: >> >> $ ls /usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib >> libQAxContainer.prllibQtNetwork.a libQtSvg.prl >> libQAxServer.prl libQtNetwork.lalibQtTest.a >> libQt3Support.la libQtNetwork.prl libQtTest.la >> libQt3Support.prl libQtOpenGL.la libQtTest.prl >> libQtCore.alibQtOpenGL.prllibQtWebKit.la >> libQtCore.la libQtOpenVG.la libQtWebKit.prl >> libQtCore.prl libQtOpenVG.prllibQtXml.a >> libQtDBus.la libQtScript.la libQtXml.la >> libQtDBus.prl libQtScript.prllibQtXml.prl >> libQtDeclarative.lalibQtScriptTools.lalibQtXmlPatterns.a >> libQtDeclarative.prl libQtScriptTools.prl >> libQtXmlPatterns.la >> libQtGui.a libQtSql.a >> libQtXmlPatterns.prl >> libQtGui.lalibQtSql.lalibpvrQWSWSEGL.prl >> libQtGui.prl libQtSql.prl pkgconfig >> libQtMultimedia.la libQtSvg.a >> libQtMultimedia.prllibQtSvg.la >> >> libQtWebkit seems to be there, right? >> >> > > libQtWebkit does not seem to be listed in /usr/ports/pobj, but the > others seem to be listed. I see QtNetwork is listed... I meant to say the .a file is missing for libQtWebkit Thanks
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 1, 2017 at 10:10 AM, Frank Groeneveldwrote: > On Wed, Mar 1, 2017, at 15:14, Stuart Henderson wrote: >> Oops, I forgot to re-run update-patches and had an old one. However >> unfortunately >> not enough as linking fails. >> > > Thanks, that gets us a lot further indeed. The complete QT build > finished and now only the final linking step fails indeed. > For the interested, this is the command: > > c++ -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -pthread > -shared -Wl,-soname,libwkhtmltox.so.0 -fPIC -o libwkhtmltox.so.0.0 > loadsettings.o multipageloader.o tempfile.o converter.o websettings.o > reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o > tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o > image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o > moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o > moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o > moc_utilities.o moc_pdfconverter.o moc_imageconverter.o > qrc_wkhtmltopdf.o-L/usr/local/lib > -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib > -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/plugins/codecs > -lqcncodecs -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib > -L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit > -L/usr/X11R6/lib -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender > -lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lQtCore -lz -lm > -liconv > /usr/bin/ld: cannot find -lQtWebKit > > Which seems weird to me, because: > > $ ls /usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib > libQAxContainer.prllibQtNetwork.a libQtSvg.prl > libQAxServer.prl libQtNetwork.lalibQtTest.a > libQt3Support.la libQtNetwork.prl libQtTest.la > libQt3Support.prl libQtOpenGL.la libQtTest.prl > libQtCore.alibQtOpenGL.prllibQtWebKit.la > libQtCore.la libQtOpenVG.la libQtWebKit.prl > libQtCore.prl libQtOpenVG.prllibQtXml.a > libQtDBus.la libQtScript.la libQtXml.la > libQtDBus.prl libQtScript.prllibQtXml.prl > libQtDeclarative.lalibQtScriptTools.lalibQtXmlPatterns.a > libQtDeclarative.prl libQtScriptTools.prl > libQtXmlPatterns.la > libQtGui.a libQtSql.a > libQtXmlPatterns.prl > libQtGui.lalibQtSql.lalibpvrQWSWSEGL.prl > libQtGui.prl libQtSql.prl pkgconfig > libQtMultimedia.la libQtSvg.a > libQtMultimedia.prllibQtSvg.la > > libQtWebkit seems to be there, right? > > libQtWebkit does not seem to be listed in /usr/ports/pobj, but the others seem to be listed. I see QtNetwork is listed...
Re: Ports with hardcoded "gcc", "g++"
On Wed, Mar 1, 2017, at 15:14, Stuart Henderson wrote: > Oops, I forgot to re-run update-patches and had an old one. However > unfortunately > not enough as linking fails. > Thanks, that gets us a lot further indeed. The complete QT build finished and now only the final linking step fails indeed. For the interested, this is the command: c++ -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -pthread -shared -Wl,-soname,libwkhtmltox.so.0 -fPIC -o libwkhtmltox.so.0.0 loadsettings.o multipageloader.o tempfile.o converter.o websettings.o reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o moc_utilities.o moc_pdfconverter.o moc_imageconverter.o qrc_wkhtmltopdf.o-L/usr/local/lib -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/plugins/codecs -lqcncodecs -L/usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib -L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit -L/usr/X11R6/lib -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender -lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lQtCore -lz -lm -liconv /usr/bin/ld: cannot find -lQtWebKit Which seems weird to me, because: $ ls /usr/ports/pobj/wkhtmltopdf-0.12.3.2/build-amd64/qt/lib libQAxContainer.prllibQtNetwork.a libQtSvg.prl libQAxServer.prl libQtNetwork.lalibQtTest.a libQt3Support.la libQtNetwork.prl libQtTest.la libQt3Support.prl libQtOpenGL.la libQtTest.prl libQtCore.alibQtOpenGL.prllibQtWebKit.la libQtCore.la libQtOpenVG.la libQtWebKit.prl libQtCore.prl libQtOpenVG.prllibQtXml.a libQtDBus.la libQtScript.la libQtXml.la libQtDBus.prl libQtScript.prllibQtXml.prl libQtDeclarative.lalibQtScriptTools.lalibQtXmlPatterns.a libQtDeclarative.prl libQtScriptTools.prl libQtXmlPatterns.la libQtGui.a libQtSql.a libQtXmlPatterns.prl libQtGui.lalibQtSql.lalibpvrQWSWSEGL.prl libQtGui.prl libQtSql.prl pkgconfig libQtMultimedia.la libQtSvg.a libQtMultimedia.prllibQtSvg.la libQtWebkit seems to be there, right? Frank
Re: Ports with hardcoded "gcc", "g++"
On 2017/03/01 12:12, Stuart Henderson wrote: > On 2017/03/01 11:02, Frank Groeneveld wrote: > > On Tue, Feb 28, 2017, at 14:03, Christian Weisgerber wrote: > > > textproc/wkhtmltopdf Frank Groeneveld> > > > I've been trying to fix textporc/wkhtmltopdf in the last few days, but > > can't seem to make qmake use the correct compiler. The do-configure step > > of this port configures the patched QT that is part of the port. I've > > tried adding CXX="${CXX}" and/or SYS_CXX="${CXX}" to the env of that > > step, but it seems to be unused. Anybody got some hints on how to fix > > this one? > > > > Thanks! > > Frank > > > > It gets further with this, build is still running so there might be > more needed. Oops, I forgot to re-run update-patches and had an old one. However unfortunately not enough as linking fails. Index: Makefile === RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v retrieving revision 1.12 diff -u -p -r1.12 Makefile --- Makefile13 Sep 2016 18:52:06 - 1.12 +++ Makefile1 Mar 2017 14:13:39 - @@ -39,7 +39,9 @@ LIB_DEPENDS = converters/libiconv \ USE_GMAKE =Yes MAKE_FLAGS = LIBwkhtmltox_VERSION=${LIBwkhtmltox_VERSION} -MAKE_ENV +=WRKBUILD=${WRKBUILD} +MAKE_ENV +=WRKBUILD=${WRKBUILD} \ + PORTS_CC="${CC}" PORTS_CXX="${CXX}" +CONFIGURE_ENV =PORTS_CC="${CC}" PORTS_CXX="${CXX}" FAKE_FLAGS = INSTALL_ROOT=${WRKINST}${TRUEPREFIX} SEPARATE_BUILD = Yes @@ -51,7 +53,7 @@ pre-patch: cd ${WRKDIR}/${DISTNAME} && mv ../qt-${QT_COMMIT} qt do-configure: - mkdir ${WRKBUILD}/qt + mkdir -p ${WRKBUILD}/qt # qt config options taken from scripts/build.py cd ${WRKBUILD}/qt && \ env -i ${CONFIGURE_ENV} ${WRKSRC}/qt/configure \ Index: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf === RCS file: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf diff -N patches/patch-qt_mkspecs_openbsd-g++_qmake_conf --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-qt_mkspecs_openbsd-g++_qmake_conf 1 Mar 2017 14:13:39 - @@ -0,0 +1,36 @@ +$OpenBSD$ +--- qt/mkspecs/openbsd-g++/qmake.conf.orig Tue May 10 09:19:52 2016 qt/mkspecs/openbsd-g++/qmake.conf Wed Mar 1 12:07:44 2017 +@@ -8,7 +8,7 @@ TEMPLATE = app + CONFIG+= qt warn_on release link_prl gdb_dwarf_index + QT+= core gui + +-QMAKE_CC = gcc ++QMAKE_CC = ${PORTS_CC} + QMAKE_LEX = flex + QMAKE_LEXFLAGS= + QMAKE_YACC= yacc +@@ -24,7 +24,7 @@ QMAKE_CFLAGS_STATIC_LIB = $$QMAKE_CFLAGS_SHLIB + QMAKE_CFLAGS_YACC = -Wno-unused -Wno-parentheses + QMAKE_CFLAGS_THREAD = -pthread + +-QMAKE_CXX = g++ ++QMAKE_CXX = ${PORTS_CXX} + QMAKE_CXXFLAGS= $$QMAKE_CFLAGS + QMAKE_CXXFLAGS_DEPS = $$QMAKE_CFLAGS_DEPS + QMAKE_CXXFLAGS_WARN_ON= $$QMAKE_CFLAGS_WARN_ON +@@ -45,10 +45,10 @@ QMAKE_LIBDIR_QT= $$[QT_INSTALL_LIBS] + QMAKE_INCDIR_OPENGL = /usr/X11R6/include + QMAKE_LIBDIR_OPENGL = /usr/X11R6/lib + +-QMAKE_LINK= g++ +-QMAKE_LINK_SHLIB = g++ +-QMAKE_LINK_C = gcc +-QMAKE_LINK_C_SHLIB= gcc ++QMAKE_LINK= $$QMAKE_CXX ++QMAKE_LINK_SHLIB = $$QMAKE_CXX ++QMAKE_LINK_C = $$QMAKE_CC ++QMAKE_LINK_C_SHLIB= $$QMAKE_CC + QMAKE_LINK_SHLIB_CMD = $$QMAKE_LINK_SHLIB $(LFLAGS) \ + $$QMAKE_CFLAGS_SHLIB $$QMAKE_LFLAGS \ + -o $(TARGETD) $(OBJECTS) $(OBJMOC) $(LIBS)
Re: Ports with hardcoded "gcc", "g++"
On 2017/03/01 11:02, Frank Groeneveld wrote: > On Tue, Feb 28, 2017, at 14:03, Christian Weisgerber wrote: > > textproc/wkhtmltopdf Frank Groeneveld> > I've been trying to fix textporc/wkhtmltopdf in the last few days, but > can't seem to make qmake use the correct compiler. The do-configure step > of this port configures the patched QT that is part of the port. I've > tried adding CXX="${CXX}" and/or SYS_CXX="${CXX}" to the env of that > step, but it seems to be unused. Anybody got some hints on how to fix > this one? > > Thanks! > Frank > It gets further with this, build is still running so there might be more needed. Index: Makefile === RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v retrieving revision 1.12 diff -u -p -r1.12 Makefile --- Makefile13 Sep 2016 18:52:06 - 1.12 +++ Makefile1 Mar 2017 12:12:09 - @@ -39,7 +39,9 @@ LIB_DEPENDS = converters/libiconv \ USE_GMAKE =Yes MAKE_FLAGS = LIBwkhtmltox_VERSION=${LIBwkhtmltox_VERSION} -MAKE_ENV +=WRKBUILD=${WRKBUILD} +MAKE_ENV +=WRKBUILD=${WRKBUILD} \ + PORTS_CC="${CC}" PORTS_CXX="${CXX}" +CONFIGURE_ENV =PORTS_CC="${CC}" PORTS_CXX="${CXX}" FAKE_FLAGS = INSTALL_ROOT=${WRKINST}${TRUEPREFIX} SEPARATE_BUILD = Yes @@ -51,7 +53,7 @@ pre-patch: cd ${WRKDIR}/${DISTNAME} && mv ../qt-${QT_COMMIT} qt do-configure: - mkdir ${WRKBUILD}/qt + mkdir -p ${WRKBUILD}/qt # qt config options taken from scripts/build.py cd ${WRKBUILD}/qt && \ env -i ${CONFIGURE_ENV} ${WRKSRC}/qt/configure \ Index: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf === RCS file: patches/patch-qt_mkspecs_openbsd-g++_qmake_conf diff -N patches/patch-qt_mkspecs_openbsd-g++_qmake_conf --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-qt_mkspecs_openbsd-g++_qmake_conf 1 Mar 2017 12:12:09 - @@ -0,0 +1,36 @@ +$OpenBSD$ +--- qt/mkspecs/openbsd-g++/qmake.conf.orig Wed Mar 1 12:02:31 2017 qt/mkspecs/openbsd-g++/qmake.conf Wed Mar 1 12:03:23 2017 +@@ -8,7 +8,7 @@ TEMPLATE = app + CONFIG+= qt warn_on release link_prl gdb_dwarf_index + QT+= core gui + +-QMAKE_CC = gcc ++QMAKE_CC = ${CC} + QMAKE_LEX = flex + QMAKE_LEXFLAGS= + QMAKE_YACC= yacc +@@ -24,7 +24,7 @@ QMAKE_CFLAGS_STATIC_LIB = $$QMAKE_CFLAGS_SHLIB + QMAKE_CFLAGS_YACC = -Wno-unused -Wno-parentheses + QMAKE_CFLAGS_THREAD = -pthread + +-QMAKE_CXX = g++ ++QMAKE_CXX = ${CXX} + QMAKE_CXXFLAGS= $$QMAKE_CFLAGS + QMAKE_CXXFLAGS_DEPS = $$QMAKE_CFLAGS_DEPS + QMAKE_CXXFLAGS_WARN_ON= $$QMAKE_CFLAGS_WARN_ON +@@ -45,10 +45,10 @@ QMAKE_LIBDIR_QT= $$[QT_INSTALL_LIBS] + QMAKE_INCDIR_OPENGL = /usr/X11R6/include + QMAKE_LIBDIR_OPENGL = /usr/X11R6/lib + +-QMAKE_LINK= g++ +-QMAKE_LINK_SHLIB = g++ +-QMAKE_LINK_C = gcc +-QMAKE_LINK_C_SHLIB= gcc ++QMAKE_LINK= $$QMAKE_CXX ++QMAKE_LINK_SHLIB = $$QMAKE_CXX ++QMAKE_LINK_C = $$QMAKE_CC ++QMAKE_LINK_C_SHLIB= $$QMAKE_CC + QMAKE_LINK_SHLIB_CMD = $$QMAKE_LINK_SHLIB $(LFLAGS) \ + $$QMAKE_CFLAGS_SHLIB $$QMAKE_LFLAGS \ + -o $(TARGETD) $(OBJECTS) $(OBJMOC) $(LIBS)
Re: Ports with hardcoded "gcc", "g++"
On Tue, Feb 28, 2017, at 14:03, Christian Weisgerber wrote: > textproc/wkhtmltopdf Frank GroeneveldI've been trying to fix textporc/wkhtmltopdf in the last few days, but can't seem to make qmake use the correct compiler. The do-configure step of this port configures the patched QT that is part of the port. I've tried adding CXX="${CXX}" and/or SYS_CXX="${CXX}" to the env of that step, but it seems to be unused. Anybody got some hints on how to fix this one? Thanks! Frank
Re: Ports with hardcoded "gcc", "g++"
> The fixes that have been committed have unlocked additional parts > of the ports tree, revealing new build failures. Here is an updated > list. I've added the MAINTAINERs .. > plan9/devdrawserver Gleydson Soaresfixed.
Re: Ports with hardcoded "gcc", "g++"
On Tue, Feb 28, 2017 at 01:03:38PM +, Christian Weisgerber wrote: > The fixes that have been committed have unlocked additional parts > of the ports tree, revealing new build failures. Here is an updated > list. I've added the MAINTAINERs. > > lang/nimThe OpenBSD ports mailing-listI've a patch for nim from two or three days ago. It builds the package but I don't find where is the gcc command in the tests and I don't want commit the changes without to run first the tests. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Ports with hardcoded "gcc", "g++"
The fixes that have been committed have unlocked additional parts of the ports tree, revealing new build failures. Here is an updated list. I've added the MAINTAINERs. archivers/hs-zlib Matthias Kilianaudio/gogglesmm The OpenBSD ports mailing-list databases/hs-postgresql-libpq David Schaefer databases/riak Jonathan Matthew devel/boost Brad Smith devel/cil The OpenBSD ports mailing-list devel/hs-bytestring-mmap Matthias Kilian devel/hs-hinotify The OpenBSD ports mailing-list devel/hs-lifted-base Matthias Kilian devel/hs-networkMatthias Kilian devel/hs-old-time Matthias Kilian devel/hs-primitive Jim Razmus II devel/hs-readline Matthias Kilian devel/hs-regex-posix Matthias Kilian devel/hs-unix-compat Jim Razmus II devel/jdk/1.7 Kurt Miller devel/libfmtMarkus Friedl devel/ocaml-curses The OpenBSD ports mailing-list devel/py-sipThe OpenBSD ports mailing-list devel/radare2/main Edd Barrett games/ioquake3 Aaron Bieber games/roadfighter The OpenBSD ports mailing-list games/teeworlds Donovan Watteau games/tome4 Solene Rapenne games/wordwarvi Pascal Stumpf geo/osm2go The OpenBSD ports mailing-list graphics/birdfont Jasper Lievisse Adriaanse graphics/hs-OpenGLRaw Matthias Kilian lang/nimThe OpenBSD ports mailing-list lang/squeak/vm Marc Espie misc/rocrailSebastian Reitenbach misc/wmtimerThe OpenBSD ports mailing-list net/clogThe OpenBSD ports mailing-list net/dysnomiaThe OpenBSD ports mailing-list net/hs-curl David Schaefer net/hs-network-info David Schaefer net/olsrd Martin Reindl net/pidgin Brad Smith net/spectrum-tools The OpenBSD ports mailing-list plan9/devdrawserver Gleydson Soares productivity/wyrd Okan Demirmen security/hs-skein The OpenBSD ports mailing-list security/ssh-askpass-fullscreen The OpenBSD ports mailing-list textproc/hs-libxml-sax David Coppa textproc/pilot_makedoc The OpenBSD ports mailing-list textproc/wkhtmltopdf Frank Groeneveld www/iridium Robert Nagy www/phantomjs Francisco de Borja Lopez Rio x11/hs-X11 Matthias Kilian x11/isomaster Giovanni Bechis x11/p5-Wx The OpenBSD ports mailing-list x11/qt3 Marc Espie x11/qt4 Marc Espie x11/roxterm The OpenBSD ports mailing-list -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Ports with hardcoded "gcc", "g++"
> plan9/plan9port fixed.
Re: Ports with hardcoded "gcc", "g++"
Hi, On Mon, Feb 27, 2017 at 09:06:22PM +0100, Jeremie Courreges-Anglas wrote: > TODO > [...] > >> lang/ghc This one is weird. It has "autodetection", but just setting CC="${CC}" doesn't work, so I've added --with-ghc="${CC}", which seems to work (with /usr/bin/gcc and /usr/bin/g++ removed). For the switch to clang, I also added --with-clang="${CC}", but I've no idea wether this will work or not. Anyway, when my ghc build finishes sucessfully, I'll put the diff below in. Ciao, Kili Index: Makefile === RCS file: /cvs/ports/lang/ghc/Makefile,v retrieving revision 1.143 diff -u -p -r1.143 Makefile --- Makefile1 Nov 2016 18:14:05 - 1.143 +++ Makefile27 Feb 2017 22:42:12 - @@ -106,7 +106,9 @@ CFLAGS += -fno-pie CONFIGURE_STYLE = gnu CONFIGURE_ARGS += --with-iconv-includes=${LOCALBASE}/include \ - --with-iconv-libraries=${LOCALBASE}/lib + --with-iconv-libraries=${LOCALBASE}/lib \ + --with-gcc="${CC}" \ + --with-clang="${CC}" # XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and # loadObj_() instead. CONFIGURE_ENV += CONF_CC_OPTS_STAGE0="-fno-pie -nopie" \ @@ -161,7 +163,9 @@ post-patch: # - Install a precompiled binary. cd ${WRKDIR}/ghc-${BIN_VER} && \ LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \ - ./configure --prefix=${WRKDIR}/bootstrap && \ + ./configure --prefix=${WRKDIR}/bootstrap \ + --with-gcc="${CC}" \ + --with-clang="${CC}" && \ LD_LIBRARY_PATH=${BOOTSTRAP_SHLIBS} \ ${MAKE_PROGRAM} install rm -rf ${WRKDIR}/ghc-${BIN_VER}
Re: Ports with hardcoded "gcc", "g++"
Stuart Hendersonwrites: > On 2017/02/26 16:00, Christian Weisgerber wrote: >> Ports are supposed to honor the CC and CXX variables. (There are >> some exceptions such as perl and imake ports that pick up a central >> setting.) They are not supposed to have hardcoded compiler names. >> In particular they should not call "gcc" or "g++". Alas, this has >> never been strictly enfored, so numerous offenders have slipped in. >> >> At least clang architectures will no longer have a /usr/bin/gcc or >> /usr/bin/g++. >> >> Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc >> and /usr/bin/g++. You can hardlink them back afterwards. >> >> Here is a first batch of ports that fail to build without "gcc" or >> "g++" being present. More will come to light eventually. At the >> moment, failing dependencies prevent about a third of the ports >> tree from being built. > > I've fixed a handful (mostly just adding CC="${CC}" and/or > CXX="${CXX}" to MAKE_FLAGS, though some needed more work) > >> audio/mp3gain >> comms/zmtx-zmrx >> converters/html2text >> misc/figlet >> net/ssvnc >> net/vncsnapshot >> telephony/astmanproxy >> security/p0f3 > > ... > > These ones are most likely qmake-related > >> devel/py-sip >> textproc/wkhtmltopdf >> www/phantomjs > > .. > Ports that should be fine now (fixed by various) >> audio/goattracker >> biology/nutdb >> chinese/crxvt >> comms/colrdx >> comms/owx >> converters/lastools >> converters/mimepp >> devel/jsoncpp >> devel/libutf >> devel/premake4 >> devel/pysvn >> devel/radare2/main >> editors/tweak >> graphics/s10sh >> mail/archiveopteryx >> mail/bmf >> math/aamath >> math/libneural >> math/libtommath >> math/minisat >> math/xspread >> misc/randtype >> misc/xd >> multimedia/avinfo >> net/osrtspproxy >> plan9/drawterm >> security/foremost >> security/ipguard >> sysutils/incron >> textproc/rman >> www/cntlm >> x11/windowlab >> x11/xmold TODO (There's a removal proposal pending for clog and pilot_makedoc.) >> devel/arm-none-eabi/gcc-linaro >> devel/avr/gcc >> devel/boost >> emulators/sdlmame >> emulators/sdlmess >> games/blockrage >> games/capitan-sevilla >> games/einstein >> games/gemdropx >> games/icebreaker >> games/netris >> games/sdlpop >> games/teeworlds >> games/typespeed >> lang/ghc >> lang/libv8 >> lang/mruby >> lang/nim >> lang/ocaml >> lang/squeak/vm >> math/suitesparse XXX kill? >> net/clog >> net/ftpcopy >> plan9/plan9port >> textproc/heirloom-doctools >> textproc/libxmlbird XXX kill? >> textproc/pilot_makedoc >> www/netsurf/netsurf-fb >> www/swiggle >> x11/goggles -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Ports with hardcoded "gcc", "g++"
On 2017/02/26 16:00, Christian Weisgerber wrote: > Ports are supposed to honor the CC and CXX variables. (There are > some exceptions such as perl and imake ports that pick up a central > setting.) They are not supposed to have hardcoded compiler names. > In particular they should not call "gcc" or "g++". Alas, this has > never been strictly enfored, so numerous offenders have slipped in. > > At least clang architectures will no longer have a /usr/bin/gcc or > /usr/bin/g++. > > Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc > and /usr/bin/g++. You can hardlink them back afterwards. > > Here is a first batch of ports that fail to build without "gcc" or > "g++" being present. More will come to light eventually. At the > moment, failing dependencies prevent about a third of the ports > tree from being built. I've fixed a handful (mostly just adding CC="${CC}" and/or CXX="${CXX}" to MAKE_FLAGS, though some needed more work) > audio/mp3gain > comms/zmtx-zmrx > converters/html2text > misc/figlet > net/ssvnc > net/vncsnapshot > telephony/astmanproxy > security/p0f3 ... These ones are most likely qmake-related > devel/py-sip > textproc/wkhtmltopdf > www/phantomjs .. > audio/goattracker > biology/nutdb > chinese/crxvt > comms/colrdx > comms/owx > converters/lastools > converters/mimepp > devel/arm-none-eabi/gcc-linaro > devel/avr/gcc > devel/boost > devel/jsoncpp > devel/libutf > devel/premake4 > devel/pysvn > devel/radare2/main > editors/tweak > emulators/sdlmame > emulators/sdlmess > games/blockrage > games/capitan-sevilla > games/einstein > games/gemdropx > games/icebreaker > games/netris > games/sdlpop > games/teeworlds > games/typespeed > graphics/s10sh > lang/ghc > lang/libv8 > lang/mruby > lang/nim > lang/ocaml > lang/squeak/vm > mail/archiveopteryx > mail/bmf > math/aamath > math/libneural > math/libtommath > math/minisat > math/suitesparse > math/xspread > misc/randtype > misc/xd > multimedia/avinfo > net/clog > net/ftpcopy > net/osrtspproxy > plan9/drawterm > plan9/plan9port > security/foremost > security/ipguard > sysutils/incron > textproc/heirloom-doctools > textproc/libxmlbird > textproc/pilot_makedoc > textproc/rman > www/cntlm > www/netsurf/netsurf-fb > www/swiggle > x11/goggles > x11/windowlab > x11/xmold > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: Ports with hardcoded "gcc", "g++"
On Sun, Feb 26, 2017 at 04:00:16PM +0100, Christian Weisgerber wrote: > Ports are supposed to honor the CC and CXX variables. (There are > some exceptions such as perl and imake ports that pick up a central > setting.) They are not supposed to have hardcoded compiler names. > In particular they should not call "gcc" or "g++". Alas, this has > never been strictly enfored, so numerous offenders have slipped in. > > At least clang architectures will no longer have a /usr/bin/gcc or > /usr/bin/g++. > > Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc > and /usr/bin/g++. You can hardlink them back afterwards. > > Here is a first batch of ports that fail to build without "gcc" or > "g++" being present. More will come to light eventually. At the > moment, failing dependencies prevent about a third of the ports > tree from being built. There's also Qt that hardcodes gcc and g++ IIRC (QMAKE_CC or something like that in the default qmake.conf). > audio/goattracker > audio/mp3gain > biology/nutdb > chinese/crxvt > comms/colrdx > comms/owx > comms/zmtx-zmrx > converters/html2text > converters/lastools > converters/mimepp > devel/arm-none-eabi/gcc-linaro > devel/avr/gcc > devel/boost > devel/jsoncpp > devel/libutf > devel/premake4 > devel/py-sip > devel/pysvn > devel/radare2/main > editors/tweak > emulators/sdlmame > emulators/sdlmess > games/blockrage > games/capitan-sevilla > games/einstein > games/gemdropx > games/icebreaker > games/netris > games/sdlpop > games/teeworlds > games/typespeed > graphics/s10sh > lang/ghc > lang/libv8 > lang/mruby > lang/nim > lang/ocaml > lang/squeak/vm > mail/archiveopteryx > mail/bmf > math/aamath > math/libneural > math/libtommath > math/minisat > math/suitesparse > math/xspread > misc/figlet > misc/randtype > misc/xd > multimedia/avinfo > net/clog > net/ftpcopy > net/osrtspproxy > net/ssvnc > net/vncsnapshot > plan9/drawterm > plan9/plan9port > security/foremost > security/ipguard > security/p0f3 > sysutils/incron > telephony/astmanproxy > textproc/heirloom-doctools > textproc/libxmlbird > textproc/pilot_makedoc > textproc/rman > textproc/wkhtmltopdf > www/cntlm > www/netsurf/netsurf-fb > www/phantomjs > www/swiggle > x11/goggles > x11/windowlab > x11/xmold > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > -- Antoine
Ports with hardcoded "gcc", "g++"
Ports are supposed to honor the CC and CXX variables. (There are some exceptions such as perl and imake ports that pick up a central setting.) They are not supposed to have hardcoded compiler names. In particular they should not call "gcc" or "g++". Alas, this has never been strictly enfored, so numerous offenders have slipped in. At least clang architectures will no longer have a /usr/bin/gcc or /usr/bin/g++. Fortunately, this is easy to test anywhere: just rm /usr/bin/gcc and /usr/bin/g++. You can hardlink them back afterwards. Here is a first batch of ports that fail to build without "gcc" or "g++" being present. More will come to light eventually. At the moment, failing dependencies prevent about a third of the ports tree from being built. audio/goattracker audio/mp3gain biology/nutdb chinese/crxvt comms/colrdx comms/owx comms/zmtx-zmrx converters/html2text converters/lastools converters/mimepp devel/arm-none-eabi/gcc-linaro devel/avr/gcc devel/boost devel/jsoncpp devel/libutf devel/premake4 devel/py-sip devel/pysvn devel/radare2/main editors/tweak emulators/sdlmame emulators/sdlmess games/blockrage games/capitan-sevilla games/einstein games/gemdropx games/icebreaker games/netris games/sdlpop games/teeworlds games/typespeed graphics/s10sh lang/ghc lang/libv8 lang/mruby lang/nim lang/ocaml lang/squeak/vm mail/archiveopteryx mail/bmf math/aamath math/libneural math/libtommath math/minisat math/suitesparse math/xspread misc/figlet misc/randtype misc/xd multimedia/avinfo net/clog net/ftpcopy net/osrtspproxy net/ssvnc net/vncsnapshot plan9/drawterm plan9/plan9port security/foremost security/ipguard security/p0f3 sysutils/incron telephony/astmanproxy textproc/heirloom-doctools textproc/libxmlbird textproc/pilot_makedoc textproc/rman textproc/wkhtmltopdf www/cntlm www/netsurf/netsurf-fb www/phantomjs www/swiggle x11/goggles x11/windowlab x11/xmold -- Christian "naddy" Weisgerber na...@mips.inka.de