[racket] SunOS-5.10-amd64: Issue with lseek64 etc. functions in xform'ed source

[Tim Brown]

Folks,

I'm trying to build racket on SunOS 5.10 with gcc:
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
(which is the system gcc)

I configure with:
../configure --prefix=/usr2/local/racket-master/SunOS-5.10-amd64
CFLAGS=-m64 LDFLAGS=-m64 --enable-shared
(Oh, I'm in an architecture dependent subdirectory of src)

and my build fails as per the extract below.

I don't think that lseek64 (et al.) are available in the 64 bit libc
libraries on solaris (at least according to nm):

> nm /usr/lib/libc.so | grep lseek64
[6606] | 701088| 14|FUNC |GLOB |0 |11 |_lseek64
[8121] | 701088| 14|FUNC |WEAK |0 |11 |lseek64
> nm /usr/lib/64/libc.so | grep lseek64
>

According to the manual, these are "transitional" functions which
allow 32 bit developers to access 64-bit sized files. And natively,
on 64-bit, they are unnecessary (and therefore not provided).

The racketcgc builds fine. The issue comes when building racket3m.
I have found in the transformed files (e.g.) ./racket/gc2/xsrc/fun.c

----------------------------------------------------
# 162 "/usr/include/sys/resource.h" 3
;

#pragma redefine_extname setrlimit setrlimit64


#pragma redefine_extname getrlimit getrlimit64
----------------------------------------------------

which causes the not provided functions to be used.

At a glance, can anyone either give me a solution, or a pointer to help me
out here; otherwise, I'll be delving into this a bit blind tomorrow.

Thanks,

Tim Brown

../../../racket/gc2/../../utils/nicear
/usr2/other/tim-brown-racket-81dc927/src/SunOS-5.10-amd64/lt/libtool
--mode=link --tag=CC gcc -XCClinker -static-libgcc -release 5.3.0.9 -rpath
/usr2/local/racket-master/SunOS-5.10-amd64/lib -m64 -ldl -lm -lsocket
-lnsl -lintl -o ../libracket3m.la salloc.lo bignum.lo bool.lo
builtin.lo char.lo compenv.lo compile.lo complex.lo dynext.lo env.lo
error.lo eval.lo file.lo fun.lo future.lo hash.lo jit.lo
jitalloc.lo jitarith.lo jitcall.lo jitcommon.lo jitinline.lo
jitprep.lo jitstack.lo jitstate.lo list.lo marshal.lo module.lo
mzrt.lo network.lo numarith.lo number.lo numcomp.lo numstr.lo
optimize.lo place.lo port.lo portfun.lo print.lo rational.lo read.lo
regexp.lo resolve.lo sema.lo setjmpup.lo sfs.lo string.lo struct.lo
symbol.lo syntax.lo thread.lo type.lo validate.lo vector.lo
foreign.lo ../src/gmp.lo ../src/unwind.lo
../../foreign/libffi/libffi_convenience.la gc2.lo
rm -fr ../.libs/libracket3m-5.3.0.9.so ../.libs/libracket3m.la
../.libs/libracket3m.lai ../.libs/libracket3m.so
gcc -shared -Wl,-h -Wl,libracket3m-5.3.0.9.so -o
../.libs/libracket3m-5.3.0.9.so .libs/salloc.o .libs/bignum.o .libs/bool.o
.libs/builtin.o .libs/char.o .libs/compenv.o .libs/compile.o
.libs/complex.o .libs/dynext.o .libs/env.o .libs/error.o .libs/eval.o
.libs/file.o .libs/fun.o .libs/future.o .libs/hash.o .libs/jit.o
.libs/jitalloc.o .libs/jitarith.o .libs/jitcall.o .libs/jitcommon.o
.libs/jitinline.o .libs/jitprep.o .libs/jitstack.o .libs/jitstate.o
.libs/list.o .libs/marshal.o .libs/module.o .libs/mzrt.o .libs/network.o
.libs/numarith.o .libs/number.o .libs/numcomp.o .libs/numstr.o
.libs/optimize.o .libs/place.o .libs/port.o .libs/portfun.o .libs/print.o
.libs/rational.o .libs/read.o .libs/regexp.o .libs/resolve.o .libs/sema.o
.libs/setjmpup.o .libs/sfs.o .libs/string.o .libs/struct.o .libs/symbol.o
.libs/syntax.o .libs/thread.o .libs/type.o .libs/validate.o .libs/vector.o
.libs/foreign.o ../src/.libs/gmp.o ../src/.libs/unwind.o .libs/gc2.o -Wl,-z
-Wl,allextract ../../foreign/libffi/.libs/libffi_convenience.a -Wl,-z
-Wl,defaultextract -ldl -lm -lsocket -lnsl -lintl -lc -static-libgcc -m64
(cd ../.libs && rm -f libracket3m.so && ln -s libracket3m-5.3.0.9.so
libracket3m.so)
creating ../libracket3m.la
(cd ../.libs && rm -f libracket3m.la && ln -s ../libracket3m.la libracket3m.la)
: ../libracket3m.la
cd ..; /usr2/other/tim-brown-racket-81dc927/src/SunOS-5.10-amd64/lt/libtool
--mode=link --tag=CC gcc -XCClinker -static-libgcc -rpath
/usr2/local/racket-master/SunOS-5.10-amd64/lib -o racket3m gc2/main.lo
libracket3m.la -m64 -ldl -lm -lsocket -lnsl -lintl
gcc -static-libgcc -o .libs/racket3m gc2/.libs/main.o -m64
./.libs/libracket3m.so -ldl -lm -lsocket -lnsl -lintl
-R/usr2/local/racket-master/SunOS-5.10-amd64/lib
Undefined first referenced
symbol in file
getrlimit64 ./.libs/libracket3m.so
lseek64 ./.libs/libracket3m.so
lstat64 ./.libs/libracket3m.so
_xmknod ./.libs/libracket3m.so
mmap64 ./.libs/libracket3m.so
open64 ./.libs/libracket3m.so
stat64 ./.libs/libracket3m.so
readdir64 ./.libs/libracket3m.so
fseeko64 ./.libs/libracket3m.so
ftello64 ./.libs/libracket3m.so
fstat64 ./.libs/libracket3m.so
ld: fatal: Symbol referencing errors. No output written to .libs/racket3m
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `../racket3m'
Current working directory
/usr2/other/tim-brown-racket-81dc927/src/SunOS-5.10-amd64/racket/gc2
*** Error code 1
make: Fatal error: Command failed for target `all'
...


--
Tim Brown <tim....@cityc.co.uk> | City Computing Limited |
T: +44 20 8770 2110 | City House, Sutton Park Road |
F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthew Flatt]

It looks like C pre-processing might be sensitive to the build mode.
Does it help to put "-m64" in CPPFLAGS instead of CFLAGS?

[Tim Brown]

Matthew Flatt wrote:
> It looks like C pre-processing might be sensitive to the build mode.
> Does it help to put "-m64" in CPPFLAGS instead of CFLAGS?

Spot on!

../configure \
--prefix=/usr2/local/racket-master/SunOS-5.10-amd64 \
CPPFLAGS=-m64 \
LDFLAGS=-m64 \
--enable-shared

Make plain-install-both works! (I've not done a full install yet, getting
the basics going for now).


One thing to note:

the src/racket/racketcgc (and 3m?) shell scripts used during the build
neatly wrap LD_LIBRARY_PATH to include the .libs directory within the
build.

However, when I build with LD_LIBRARY_PATH_64 set (which it is in my
user environment), the .libs directory is not set into LD_LIBRARY_PATH_64
(because there is no script to do so). ld.so.1 sees that we're running a
64-bit executable, and uses the ..._64 environment variables if they are
set.

So to do a "make", or a "make ...install"; I need to
"unset LD_LIBRARY_PATH_64". I suspect this is a general issue with
any system that uses ld.so / ld.so.1, e.g. SunOS and Linux. I guess it
would also be a problem on a 32 bit build where LD_LIBRARY_PATH_32 is set.

I've not seen any reports of this being a problem on the mailing list.
Should it be handled though?

Tim

[Matthew Flatt]

At Thu, 31 May 2012 13:50:10 +0100, Tim Brown wrote:
> One thing to note:
>
> the src/racket/racketcgc (and 3m?) shell scripts used during the build
> neatly wrap LD_LIBRARY_PATH to include the .libs directory within the
> build.
>
> However, when I build with LD_LIBRARY_PATH_64 set (which it is in my
> user environment), the .libs directory is not set into LD_LIBRARY_PATH_64
> (because there is no script to do so). ld.so.1 sees that we're running a
> 64-bit executable, and uses the ..._64 environment variables if they are
> set.
>
> So to do a "make", or a "make ...install"; I need to
> "unset LD_LIBRARY_PATH_64". I suspect this is a general issue with
> any system that uses ld.so / ld.so.1, e.g. SunOS and Linux. I guess it
> would also be a problem on a 32 bit build where LD_LIBRARY_PATH_32 is set.
>
> I've not seen any reports of this being a problem on the mailing list.
> Should it be handled though?

This sounds like an `--enable-shared' and libtool issue. Maybe we need
to upgrade some libtool files?

[Tim Brown]

Matthew Flatt wrote:
> This sounds like an `--enable-shared' and libtool issue. Maybe we need
> to upgrade some libtool files?

Do you import libtool into the racket source tree, thereby freezing
the version and needing maunal update?

--
Tim Brown <tim....@cityc.co.uk> | City Computing Limited |
T: +44 20 8770 2110 | City House, Sutton Park Road |
F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.

[Matthew Flatt]

At Thu, 31 May 2012 14:03:00 +0100, Tim Brown wrote:
> Matthew Flatt wrote:
> > This sounds like an `--enable-shared' and libtool issue. Maybe we need
> > to upgrade some libtool files?
>
> Do you import libtool into the racket source tree, thereby freezing
> the version and needing maunal update?

Yes, the bundled one is used by default. You can use the one in your
path by configuring with

--enable-lt=libtool

Maybe the default these days should be to use an installed `libtool' if
one is available?

[Tim Brown]

Matthew Flatt wrote:
> Yes, the bundled one is used by default. You can use the one in your
> path by configuring with
>
> --enable-lt=libtool
>
> Maybe the default these days should be to use an installed `libtool' if
> one is available?
>

Maybe, would you say the same of the Boehm GC (that is one of the CGC's
isn't it)?

--
Tim Brown <tim....@cityc.co.uk> | City Computing Limited |
T: +44 20 8770 2110 | City House, Sutton Park Road |
F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.

[Matthew Flatt]

At Thu, 31 May 2012 14:30:17 +0100, Tim Brown wrote:
> Matthew Flatt wrote:
> > Yes, the bundled one is used by default. You can use the one in your
> > path by configuring with
> >
> > --enable-lt=libtool
> >
> > Maybe the default these days should be to use an installed `libtool' if
> > one is available?
> >
>
> Maybe, would you say the same of the Boehm GC (that is one of the CGC's
> isn't it)?

No, I think we still rely on Racket-specific changes to the Boehm GC,
but revisiting that is on my list of things to do one day.

[Tim Brown]

Matthew Flatt wrote:
> No, I think we still rely on Racket-specific changes to the Boehm GC,
> but revisiting that is on my list of things to do one day.
>

Do you have a published LOTTDOD?

--
Tim Brown <tim....@cityc.co.uk> | City Computing Limited |
T: +44 20 8770 2110 | City House, Sutton Park Road |
F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.

[Tim Brown]

Matt,

Just saw you commit: "configure: use installed `libtool' by default"
Did you look to see whether up-to-date libtool handles the
LD_LIBRARY_PATH_nn variables?

Tim

Matthew Flatt wrote:
> Maybe the default these days should be to use an installed `libtool' if
> one is available?
>

--
Tim Brown <tim....@cityc.co.uk> | City Computing Limited |
T: +44 20 8770 2110 | City House, Sutton Park Road |
F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.