linking on Sun Solaris

[Lutz]

For some time now I have the following problem linking at Sourceforge on a Sparc R220 with "Sun Microsystems Inc. SunOS 5.9 Generic May 2002", after compiling and linking without any errors/warnings I get:



BFD: stJfaGYu: warning: allocated section `.interp' not in segment

make[1]: Leaving directory `/home/users/l/lu/lutzsf/newlisp_7508'



when trying to run newlisp I get:



~/newlisp_7508> ./newlisp

newlisp: Cannot find ⌂ELF☺☻☺

Killed

~/newlisp_7508>



There is no symbol 'interp' anywhere in my code. Nobody using newLISP on Solaris has complained and I believe everybody else has no problems. I believe this is some kind of configuration problem? On the other side I can compile/link/run a short helloworld.c fine.  The whole thing started after Sourceforge upgraded/reconfigured their servers. The same code previously would link/run fine.



Any idea? Peter aren't you running Solaris or Hans-Peter (some of the folks at your site?)



Lutz

[HPW]

I have not test the last dev-builds on our solaris host, so I can not say something about it. We have 7.5.0 running there.

I will test tomorrow when I find a bit of time.

[Lutz]

If 7500 is fine at your site, then you will not have a problem with 7508 either



Lutz



ps: seems to be a Sourceforge specific problem

[newdep]

Little offtopic but slightly related:



Hello Lutz,



I could test the compilation on tru64 4.x and 5.x

Do you know if there are some issue to expect perhpas on tru64 ?



Norman.

[Lutz]

Absolutely you will have problems :(, on 64 bit systems it will complain about int and pointers not having the same size! The 32bit version of newLISP relies on this!



I had a similar situation before when moving from 16bit to 32bit Windows. As soon as 64bit gets more mainstream (and I have access to a machine) I will do a 64bit compile flavor for newLISP.



here is a little program in the distribution called 'types.c' compile and run it to see how that OS/Compiler sees short, int, long pointers etc.



Lutz

[HPW]

Just tested 7.5.8 on our sun-host.

Compiles and run without problems.

[newdep]

I just tried to compile 7508 on the 5.6 Solaris here but got dumped...



Ill seek an other Sun machine to compile on I suspect the socket header

files not to be complete overhere...





/newlisp_7508> make sun

make: Fatal error: Don't know how to make target `sun'

/newlisp_7508> make solaris

make -f makefile_solaris

gcc -Wall -pedantic -Wno-uninitialized -c -O2 -g -DSOLARIS -DOPSYS=4 nl-sock.c

nl-sock.c: In function `p_netAccept':

nl-sock.c:351: `socklen_t' undeclared (first use in this function)

nl-sock.c:351: (Each undeclared identifier is reported only once

nl-sock.c:351: for each function it appears in.)

nl-sock.c:351: parse error before `dest_sin_len'

nl-sock.c:356: `dest_sin_len' undeclared (first use in this function)

nl-sock.c: In function `getPeerName':

nl-sock.c:377: `socklen_t' undeclared (first use in this function)

nl-sock.c:377: parse error before `address_sin_len'

nl-sock.c:382: `address_sin_len' undeclared (first use in this function)

nl-sock.c: In function `p_netReceiveUDP':

nl-sock.c:596: warning: pointer targets in passing arg 6 of `recvfrom' differ in signedness

nl-sock.c: In function `serverFD':

nl-sock.c:871: `socklen_t' undeclared (first use in this function)

nl-sock.c:871: parse error before `dest_sin_len'

nl-sock.c:881: `dest_sin_len' undeclared (first use in this function)

*** Error code 1

make: Fatal error: Command failed for target `nl-sock.o'

Current working directory /newlisp_7508

*** Error code 1

make: Fatal error: Command failed for target `solaris'









Norman.

[newdep]

indeed... Mmmm..





[ tru64 Types.c output ]

char      1

char *    8

short int 2

int       4

long      8

long long 8

float     4

double    8



[ solaris types.c output ]



char      1

char *    4

short int 2

int       4

long      4

long long 8

float     4

double    8



[ Linux types.c output ]



char      1

char *    4

short int 2

int       4

long      4

long long 8

float     4

double    8

[Lutz]

The output of tru64 is exactly like 64 bit Linux on an AMD64. Pointersize and long are both 8 and double is 8 too.



This would make a great 64bit newLISP with 64 bit integers and faster simpler routines for all floating point stuff, because now the whole double fits in one word.



After 8.0 is out, I will try to get something together for 64 bit on the AMD64, which I can use at the Sourceforge compile farm.



I also wonder if these 64 bit systems come with some sort of compatibility compile mode, because there is an awful lot of software out there written for 32 bit.



Lutz

[nigelbrown]

This post seems to discuss amd64 bit compatibility of 32bit apps:

http://lists.suse.com/archive/suse-amd64/2004-Feb/0210.html">http://lists.suse.com/archive/suse-amd6 ... /0210.html">http://lists.suse.com/archive/suse-amd64/2004-Feb/0210.html



and mentions a -m32 switch and using the correct 32bit libraries

[Lutz]

thanks for the tip, this makefile works on 64 bit Linux on a AMD64 bit CPU:

Code Select Expand


# makefile for newLISP v. 7.x.x on 64 bit LINUX tested on AMD64
#
# Note, that readline support may require different libraries on different OSs
#

OBJS = newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o
        nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o pcre.o

#CFLAGS = -m32 -Wall -pedantic -c -O2 -g -DNANOSLEEP -DREADLINE -DOPSYS=1
#CFLAGS = m32 -Wall -pedantic -Wno-uninitialized -c -O2 -g -DNANOSLEEP -DREADLINE -DOPSYS=1
CFLAGS = -m32 -Wall -pedantic -Wno-uninitialized -c -O2 -g -DNANOSLEEP -DOPSYS=1
CC = gcc


default: $(OBJS)
#       $(CC) $(OBJS) -m32 -g -lm -ldl -lreadline -ltermcap -o newlisp
#       $(CC) $(OBJS) -m32 -g -lm -ldl -lreadline -lncurses -o newlisp
        $(CC) $(OBJS) -m32 -g -lm -ldl -o newlisp
        strip newlisp

.c.o:
        $(CC) $(CFLAGS) $<

$(OBJS): primes.h protos.h makefile_linux64


Its basically the normal Linux makefile but with -m32 on the compile and link line. This will be included in 7.5.9.



Lutz

[newdep]

So that would make it run on Tru64 then :-)

(if "cc" supports it...dunno actualy..but i guess it should...)



Norman.

[newdep]

Oke..tried the -m32 for Tru64 4.0F (dont have 5.1B at hand now) but for GCC

that gives problems.. because the GCC on the 4.0F is not enhanced for 32Bits.



So tried it with CC on tru64 but then an error came up reagrding an struct

that had a failure, i guess its related to a pointer length issue on 64bits..



(define (On-success) ( (report-back))



Norman.