Date: Mon, 02 Feb 2015 16:00:22 +1100 From: Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> To: Daniel Morante <daniel@morante.net> Cc: freebsd-ports@freebsd.org Subject: Re: Use GCC only for specific ARCH Message-ID: <54CF0466.9020201@heuristicsystems.com.au> In-Reply-To: <5488002D.6080200@morante.net> References: <5488002D.6080200@morante.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/12/2014 7:11 PM, Daniel Morante wrote: > I have a port that builds fine on a 9.3 amd64, but on 9.3 i386 it > fails on this line: > > inline int64 GetMaxMoney() { return nBestHeight <= HARDFORK_HEIGHT_1 ? > 50000000000 * COIN : 25000000000 * COIN; } > > With the following error: > > "integer constant is too large for 'long' type" > > If I add "USE_GCC=yes" to the port's Makefile, it builds successfully > on i386. I'd like to apply this 'fix' only to the 32-bit platform so > I did the following: > > .if ${ARCH} == "i386" > USE_GCC=yes > .endif > > Is that the 'correct' way to do things? > > The port can be found here: > https://github.com/tuaris/FreeBSD-Coin-Ports/blob/master/ports/kittehcoin/Makefile#L80 > > Daniel, In addition to USE_GCC=yes in your make.conf, you'll also need to add to /etc/libmap.conf libgcc_s.so.1 gcc48/libgcc_s.so.1 libgomp.so.1 gcc48/libgomp.so.1 libobjc.so.4 gcc48/libobjc.so.2 libssp.so.0 gcc48/libssp.so.0 libstdc++.so.6 gcc48/libstdc++.so.6 # I don't believe I use these, but to easily avoid further troubleshooting, they're here libatomic.so.1 gcc48/libatomic.so.1 libgomp.so.1 gcc48gcc48/libgomp.so.1 libquadmath.so.0 gcc48/libquadmath.so.0 So with libmap.conf configured, a simple cd /usr/ports/security/nmap && make clean deinstall package; pkg add nmap-6.47.txz results in, I've added the '<<<<<' for reference: # ldd /usr/local/bin/nmap /usr/local/bin/nmap: libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80095d000) libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0x800bd0000) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800e15000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801081000) libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x80148c000) libm.so.5 => /lib/libm.so.5 (0x801796000) libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x8019bd000) <<<<<< libc.so.7 => /lib/libc.so.7 (0x801bd2000) libthr.so.3 => /lib/libthr.so.3 (0x801f76000) without libmap.conf you'll have /usr/local/bin/nmap: libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80095d000) libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0x800bd0000) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800e15000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801081000) libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x80148c000) libm.so.5 => /lib/libm.so.5 (0x801796000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8019bd000) <<<<<< libc.so.7 => /lib/libc.so.7 (0x801bcb000) libthr.so.3 => /lib/libthr.so.3 (0x801f6f000) Aside: I came across this as I was getting 'bus error' while building /usr/ports/security/p5-IO-Socket-SSL with march=prescott. As it turns out, the problem was repeatable with echo 'eval { require Net::SSLeay; $Net::SSLeay::trace=1; Net::SSLeay::randomize(); };' > /tmp/a; perl /tmp/a bus error Rebuilding SSLEAY and perl5.20 with gcc enabled me to continue working, without changing my CFLAGS statement CFLAGS= -O2 -pipe -g0 -ggdb0 -march=prescott -mtune=prescott -fno-strict-aliasing I initially tried to turn off stack-protector, however even applying to /etc/make.conf WITHOUT_SSP=yes SSP_UNSAFE=yes perl5.20 continued to add --stack-protector to CFLAGS. Yes, I even mv bsd.ssp.mk bsd.ssp.mk-hide; touch bsd.ssp.mk it was simply too elusive... I should mention that I added to make.conf the following as I also use ccache (3.2) CC:=/usr/local/libexec/ccache/gcc48 cc:=/usr/local/libexec/ccache/gcc48 gcc48:=/usr/local/libexec/ccache/gcc48 CXX:=/usr/local/libexec/ccache/g++48 c++:=/usr/local/libexec/ccache/g++48 g++48:=/usr/local/libexec/ccache/g++48 I suspect that I should only need CC and CXX, but I'm not very technical. Thanks for your hint about USE_GCC=yes in make.conf, along with https://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html It started me down an alternate road :) After clearing the ccache and /var/ports, my first attempt of using gcc48 using -march pentium3 (on i386) and core2 (on amd64), failed to build 7 ports; interestingly using clang they successfully built all 655 packages. (??) Regards, Dewayne. -- For the talkers: “The superior man acts before he speaks, and afterwards speaks according to his action.” For everyone else: “Life is really simple, but we insist on making it complicated.”
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54CF0466.9020201>