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>