Hi airdoc,
In the absence of any better advice, you could try building with MinGW and dmake (assuming your using a recent build of ActivePerl - 815, or later). At least the binaries built by the MinGW (gcc) compiler will use exactly the same runtime as your perl uses.
To install dmake, grab the latest version of it from
CPAN and install it as per the instructions in the
'Readme.txt' that comes with the distribution.
For MinGW, go to sourceforge and download
then run the installer. You'll need
to add the MinGW\bin folder to the path - unless the installer does that for you.
Then check that 'perl -V:cc' reports 'gcc' and try building again from scratch by running 'perl Makefile.PL', 'dmake test', 'dmake install'. If the build procedure fails, report the errors and we might be able to help. Sorry - that's the best I can come up with. I couldn't find a ppm distro of it ... which, in itself, is not a good sign.
Cheers,
Rob | [reply] |
I don't have any direct suggestions as to what you're doing wrong,
but you could try the Dependency Walker (depends.exe1),
a nifty application to debug problems with shared library loading.
Highly recommended, BTW (hehe, me (a hardcore Unix gal) recommending a
Windows tool, that does mean something... ;)
Either load your DLL associated with the DBD::Sybase extension
into the tool, or - preferably - use its "profiling" feature, i.e.
watch a running application (perl, in this case) to see what dynamic
libs it loads (or tries to load). For this, open perl.exe and
run it (F7), with your script supplied as program arguments. Then
inspect the module dependency tree, version numbers, etc... (you probably want to press F9 to
see the absolute paths). Dependency walker comes with a reasonably good
online help, for example explaining the different types of dependencies,
like implicit, explicit, forward, delay-load... I'd suggest you read it :)
As you're using Win XP, it might be a problem with incorrectly set
up or missing side-by-side assemblies —
a feature introduced with XP, which allows applications to specify
specific versions and/or locations of files they depend on, e.g.
shared libs. This is closely related to manifest files,
in other words, messing with those might be a way to work around (or
at least investigate) problems of this kind. Unfortunately, this whole
topic is rather complex, so I won't even attempt to describe any details
here. If you're interested, you might want to follow the links from the
(more or less arbitrarily chosen) pages I linked to.
Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies
might be another good page to start.
Hope this helps,
Almut
___
1 depends.exe should come with the
respective compiler suite (if you opt to install the Platform SDK),
typically in a directory ...\tools\bin. In case you really can't
get hold of it, you could also try dumpbin /DEPENDENTS
| [reply]
[d/l]
[select] |
| [reply] |