[erlang-questions] : build 64bit Erlang on Solairs

[Raymond Xiong]

On 05/05/08, Raimo Niskanen wrote:
> > 
> > If so, however, isn't it better to add CFLAGS in the follwing
> > line in erts/emulator/Makefile.in?
> > 
> > $(BINDIR)/$(EMULATOR_EXECUTABLE): $(INIT_OBJS) $(OBJS)
> >         $(PURIFY) $(LD) -o $(BINDIR)/$(EMULATOR_EXECUTABLE) \
> >         $(HIPEBEAMLDFLAGS) $(LDFLAGS) $(DEXPORT) $(INIT_OBJS) $(OBJS) $(LIBS)
> > 
> 
> It sounds weird to add CFLAGS to the LD command line.
> 

I agree it's better to use "LDFLAGS=-m64".

> > > 
> > > env CFLAGS='-m64 -O2' LDFLAGS=-m64 ./configure ; make
> > > 
> > > also works; I just did that to build R12B-2 on a Solaris 10 box.
> > 
> > Yes, I believe it would work(I haven't try it on my SPARC box yet,
> > because the machine is slow and it takes more than half an hour
> > to finish).
> > 
> > However, I doubt if you can enable ssl support. I expect the
> > following command would fail because mixing of 32-bit objects
> > and 64-bit objects is not permitted:
> > 
> >   env CFLAGS='-m64 -O2' LDFLAGS=-m64 ./configure --with-ssl=/usr/sfw \
> >   --enable-dynamic-ssl-lib ; make
> > 
> > 64bit ssl lib is under /usr/sfw/lib/64, do you have any suggestion
> > on how to let Erlang use 64bit ssl lib under that subdir(but header
> > files are still under /usr/sfw/include of course)?
> > 
> 
> In our nightly builds we have a directory early in the path
> that contains two scripts, essentially:
> gcc:
> 	#! /bin/sh
> 	exec /usr/local/pgm/.../bin/gcc -m64 ${1+"$@"}
> ld:
> 	#! /bin/sh
> 	exec /usr/ccs/bin/ld -64 ${1+"$@"}
> and we set:
> PATH=/usr/local/bin:/usr/sfw/bin:...
> LD_LIBRARY_PATH=/usr/local/lib:/usr/sfw/lib
> LD_LIBRARY_PATH_64=/usr/sfw/lib/64
> 
> We have it building and running, but it is not a pretty solution.

Thanks for the tip. It (and the command Mikael mentioned before)
helped me to identify where these issues were. However, I cannot
use it because a) it doesnt' work out of box b) the hack cannot
be accepted in my build environment.

I have two patches for erts/configure and lib/orber/c_src/Makefile.in
to fix this issue. It works for me on Solaris, so it may be
helpful to others. Here are the introductions:

$ cd otp_src_R12B-1/
$ gpatch -p0 < orber_lib_makefile.patch
$ gpatch -p0 < erts_configure.patch
$ env CC=gcc CFLAGS='-m64 -O3' LDFLAGS="-m64" CPPFLAGS="-I /usr/include/gd2" CXX=g++ ./configure --prefix=/usr --with-ssl=/usr/sfw --enable-dynamic-ssl-lib
$ gmake

With above steps, I can build 64bit executables and shared
objects. The only issue is erl_rx_driver.so:

$  file ./lib/common_test/c_src/erl_rx_driver.so
./lib/common_test/c_src/erl_rx_driver.so:	ELF 32-bit MSB
dynamic lib SPARC Version 1, dynamically linked, not stripped

The reason is its Makefile is hardcoded, rather than generated
by configure script(there is no Makefile.in under this subdir).
I decide to skip the issue for now.

Another thing is that  I think the use of LD_LIBRARY_PATH is due
to a bug in lib/crypto/c_src/Makefile.in, which I reported a 
while back:

  http://www.erlang.org/pipermail/erlang-patches/2008-March/000241.html

-- 
Regards,
Raymond
-------------- next part --------------
--- erts/configure.orig	Sun May  4 23:17:15 2008
+++ erts/configure	Mon May  5 00:34:55 2008
@@ -20722,6 +20722,12 @@
 	SSL_LIBDIR="$with_ssl/lib/VC"
     else
 	SSL_LIBDIR="$with_ssl/lib"
+	if test "$GCC" = yes && echo $CFLAGS | grep "\-m64" >/dev/null; then
+		case $host_os in
+		  solaris2*)
+ 			SSL_LIBDIR="$with_ssl/lib/64";;
+		esac
+ 	fi
     fi
     SSL_INCLUDE="-I$with_ssl/include"
     OPENSSL_CMD="$with_ssl/bin/openssl"
-------------- next part --------------
--- lib/orber/c_src/Makefile.in.orig	Sun May  4 22:36:42 2008
+++ lib/orber/c_src/Makefile.in	Sun May  4 22:38:06 2008
@@ -102,7 +102,7 @@
 	-mkdir -p $(BINDIR)
 
 $(BINDIR)/obj_init_port: $(OBJ_FILES)
-	$(CC) -o $@ $(OBJ_FILES) $(LIBS)
+	$(CC) -o $@ $(ALL_CFLAGS) $(LDFLAGS) $(OBJ_FILES) $(LIBS)
 
 $(OBJDIR)/%.o: %.c
 	$(CC) -c -o $@ $(ALL_CFLAGS) $<