[plt-scheme] Dynamic loading of multiple mzscheme modules on hpux built with SWIG

Matthew,

A few points:

1. I am not HP's ambassador to PLT Scheme; I'm just trying to build
    a working version. That's all :-) [and more about that later].

2. Bearing in mind that I have no authoritative position on this,
    I suspect that HP/UX 9 is obsolete. It dates back to the early 1990's
    (the latest disks I have are 1995) and in 1996 I was receiving
    10.10 disks. [This based on an analysis of a dusty CD cabinet].

    I cannot see that HP would have Y2K certified 9 (they didn't even
    certify our HP720 workstation, in fact), and suspect that even if
    folk hadn't upgraded to 10 when it was released they would have put
    10 (or 11) on for 1/1/2000.

3. I don't know if 10 uses dlopen(), but there were many changes to
    HP/UX to bring it into line with what most other UNIXes used (ah...
    I remember, including ELF).

I would say that you're safe enough conditioning this on the HPUX operating
system, regardless of version.



As I said before, I'm trying to get a working version of mzscheme (at
least) running on HP/UX PARISC 2 *64 bit*.

I am configuring it with a fairly simple config line:

./configure \
   --prefix=/usr2/ccl/plt \
   --disable-foreign \         FFI isn't implemented on HP
   --enable-shared \           I need shared estensions
   CC="cc +DD64" CXX="aCC +DD64" \  +DD64 builds 64 bit object filex
   CFLAGS="-Ae" \                   Extends ANSI C(++) for long long
   CPPFLAGS="-I/usr/local/include" # where I have zlib.h

I use the CC="cc +DD64" whenever I encounter a 'configure' script,
it seems to set the tone nicely.

This 'configure's and 'make's fine (i.e. without any errors);
and 'make install' runs all the way to building the .zo's for
hierlist. At which point mzscheme (the install script) spins
without terminating. I can leave it for 20 minutes, and apart from
consuming memory (600MB after that long), it can be breaked with
a 'user break' and it has a reasonable stack (depth about 200 calls
deep -- it's not recursing as from what I can tell from that).

If I move hierlist out of the way (out of collects); the build continues
and this condition occurs again at professorj's parser tools.

Is this symptomatic of anything you recognise?

Is there anything that hierlist and ProfJ's Parser tools have in common
that the other modules don't?

Is mzscheme proven to work on HP/UX or any other 64 architectures?
Is the garbage collector?

Should I be looking for anything in particular on the stack?

Why is HP/UX always the pig to build on with otherwise perfectly
serviceable software? (That one's rhetorical)

Help would be most appreciated.

Regards,

Tim

Matthew Flatt wrote:
> At Wed, 30 Mar 2005 15:12:58 +0100, Tim Brown wrote:
> 
>>I cannot get hp's shl_load() mechanism to work in the desired way
>>(it always results in the symbols being resolved as I describe below).
>>
>>By setting scheme to use dlopen() and family; I can build .so extensions
>>which link as expected. Using the mzc linker:
> 
> 
> Thanks - should I try to conditionalize this change on the OS version,
> or do you imagine that essentially all HP/UX users have switched to a
> recent enough version?
> 
> Thanks,
> Matthew

-- 
Tim Brown <tim.brown at 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.__________/