[MacPerl] Build Advice from Codewarrior/MacOS experts requested

[Arved Sandstrom <Arved_37@chebucto.ns.ca>]

Hi, all

My build of Math::Random has encountered some hitches, and so I'm throwing
this out there for comment. I'm not strong on MacOS, so maybe someone will
see something I should be trying. :-)

Math-Random-0.6 consists of 5 source files, and a header.  As of earlier 
this week I thought I'd built it for PPC, and that there was some linking 
problem with CFM only.  Well, the problem specific to CFM went away when I 
compiled a new MathLib with the far model, and I figured I was set.  The 
PPC build tested out under MPW, and I schlepped the entire dist over to 
Chris.

Fortunately he uses the MacPerl app much more than I do, and he tested 
under that.  Dynaloader barfs on dl_load_file() with a -2807 Code Fragment 
Manager error, which is "fragHadUnresolveds", or "Loaded fragment has 
unacceptable unresolved symbols". I verified this result on my own machine 
later on. This is just under the app; the same library works with the tool 
in MPW. So I figure that GetDiskFragment() in dl_mac.xs is failing out.

I went and looked at Random.exp. My first question: why is only the 
bootstrap, "boot_Math__Random", being exported? (This is all happening in 
file "wrapper.c", which is SWIG, BTW.) I would have thought that where 
Random.pm is using, for example, function "genbet" from wrapper.c, which
is mapped in the bootstrap as

newXS("Math::Random::genbet", _wrap_genbet, file);

that one would want to export _wrap_genbet so that Random.pm has access to 
code for "genbet" after the bootstrap. Or does the bootstrap mysteriously 
understand Codewarrior export conventions? :-)

So I tried exporting all of the functions from wrapper.c that are called
in Random.pm. Other than the fact that everything still happily links, it 
doesn't fix the problem one iota. And of course, each new library variant 
still works in MPW. Just not under the app. Which baffles me, too. Finally 
I tried exporting *all* symbols, as an experiment - same thing.

So I'm wondering what gives. What would really please me is if someone
with the default build setup described in MPPE could give this module a whirl, 
and see if _they_ can build it for MacPerl (the app).

This is pretty arcane, so bear with me. Thanks. It _is_ related to getting
stuff built for MacPerl, so I think it's relevant. I haven't run into this
particular problem before, and I'm thinking it's maybe related to the fact
that SWIG was used, although the code appears to be OK.

Apologies to Kevin L. for sending a faulty binary over - you're probably
scratching your head over error -2807 right now. I figure I'll have this
thing worked out within a week - I've got the bit in my teeth. :-)

Thanks very much for any suggestions. Arved



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch