Problems with ISA 1.20 and building runners

Jonathan, this one's probably for you or a co-worker... I've had a problem building 7.30.UC1 runners on SCO Openserver 5.0.4, and the same problem manifested today as I've attempted to install Informix Server Administrator 1.20 - specifically, the bundled perl executable craps out with the same error I got when attempting to link runners. So what's the problem what's the problem I hear you eagerly asking? This is what the bundled Perl says, and it's a direct analogue for the problem that came out of the runner link: dynamic linker: perl/bin/perl: symbol not found: dlopen ./installisa: 22917 Killed Informix Server Administrator installation failed. Now, with a bit of snooping in the case of the runner link, I guessed that maybe someone forgot to include <dlfcn.h> in the critical file in the library construction for SCO, and I "solved" my runner linking problem by adding putting this bandaid on the build: <EXTRA CODE LINKED INTO RUNNER> extern void *_dlopen(const char *, int); extern void *_dlsym(void *, const char *); extern int _dlclose(void *); extern char *_dlerror(void); void *dlopen(const char *cp, int i) { return _dlopen(cp, i); } void *dlsym(void *vp, const char *cp) { return _dlsym(vp, cp); } int dlclose(void *vp) { return _dlclose(vp); } char *dlerror(void) { return _dlerror(); } </EXTRA blah blah blah> Now the 7.30.UC1 runner links and works. So there's clearly a failure to build with the appropriate dl* includes and/or function names on SCO. Seems like the same guilty party is doing the same thing for the Perl bundled with ISA 1.20 for SCO? OR - are you guys using gcc now? I'm a strong believer in using the official (pay for) compilers, at least on SCO and HP because they work 100% and I'm a bit gun-shy from the older, crustier versions of gcc where you had to piss around for days, and of course there's always the support issue. What's going on and how do I get past the problem? And how does it get stopped in future? What support account at Informix should I e-mail this problem to? I'm a bit dubious of the effectiveness of putting this thru the standard support channels, because it's not your typical support problem. -- Andrew Hamm Technical Consultant Sanderson Australia Pty Ltd e-mail: <mailto:ahamm@sanderson.net.au> web: <http://www.sanderson.net.au>; -- "having fun is half the fun" - Guru Adrian