Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi I am facing an error in Cygwin, when I run Perl scripts which talks to DLL files

Laptop specification: HP Elite book Model – 8540W Intel i5 64 bit processor Win XP OS

Software – Cygwin Additional modules – Inline & Parse Rec descent.

My Perl installation in Cygwin is done properly, I am sure about that (I ran some simple “hello world” kind of scripts & that is working fine). I checked the installation of Inline & Parse Rec Descent it has installed it properly. I checked this using “make test” script, I get all the tests are passing in both Inline & Parse Rec descent.

When I run Perl scripts which uses DLL files I get this error, Please see the error below. My Perl scripts uses *.PM Perl modules which talks to DLL files of a particular hardware. As per the error below it couldn’t find some the files at run time or compiling stage, however, I checked it all the required files are present in the _Inline folder. I don’t understand why it couldn’t load it at run time or compile time….!

This is the error.

Had problems bootstrapping Inline module 'Corelis_JTAG_6bd5' Can't load '/cygdrive/c/test/_Inline/lib/auto/Corelis_JTAG_6bd5/Coreli +s_JTAG_6bd 5.dll' for module Corelis_JTAG_6bd5: No such file or directory at /usr +/lib/perl5 /5.8/cygwin/DynaLoader.pm line 230. at /usr/lib/perl5/site_perl/5.8/Inline.pm line 500 at Corelis_JTAG.pm line 25 BEGIN failed--compilation aborted at Corelis_JTAG.pm line 25. Compilation failed in require at ./crm_bist.pl line 33. BEGIN failed--compilation aborted at ./crm_bist.pl line 33.


Moreover, the same Cygwin installation, Inline version, Parse Rec descent is done the same way in other two IBM Desktops & one TOSHIBA laptop. There is literally no difference between the scripts & installation in other PC's. However, the new laptop I am trying is not going through & it throughs me the above error. But, in my IBM PC & Toshiba laptop works fine. The new laptop which is not working is HP Elite book 8540W with SATA SSD hard disk.

However, ALL the required files are present in the "_inline" folder. Assume, if the required files are not present, then how is it possible for it to run in another couple of Desktops & other laptop with all files & executables retained same - like Cygwin software, Inline module, Parse Rec descent module, Perl scripts (no change has happened here literally). I used my thumb drive to copy the scripts from a working desktop (scripts executes fine in this desktop) & pasted in my laptop. If it CAN work in other Desktops's & laptops why not this laptop is my question?

This leaves me to suspect two things.

1. The OS (Win XP) security settings problem!!!!!! (The Win XP in the desktop & laptop is about 5 years old version of Win XP - I don't know what would help there to you to debug this..)

2. The hard disk in IBM desktop is IDE & the one in Toshiba laptop is SATA2!!!!. The new laptop which is not working is HP Elite book 8540W with SATA SSD hard disk. Does hard disk matters for Cygwin at all.. Any ways what I did was to clone the working hard disk from Desktop with the hard disk in my HP laptop. Later I booted the HP hard disk in the IBM Desktop all works fine here (All scripts runs fine). However, I couldn't boot the HP hard disk in the HP laptop because, the drivers required for the latest laptop was not present in the old Win XP.

Do you think the above two reasons would make anything to fail in Cygwin, what dependencies they have with respect to Cygwin.

Please help. Shasi
  • Comment on FW: Cygwin 2.510.2.2 - Bootstrapping inline module error in Win XP OS in HP laptop which has Intel i5 64 bit processor.
  • Download Code

Replies are listed 'Best First'.
Re: FW: Cygwin 2.510.2.2 - Bootstrapping inline module error in Win XP OS in HP laptop which has Intel i5 64 bit processor.
by Anonymous Monk on Oct 22, 2010 at 19:19 UTC
    load Corelis_JTAG_6bd 5.dll using dependencywalker or fileanalyzer and find which dependency is missing from your %PATH%, (or $PATH)
      Thanks for your reply. Looks like all the dependency files are intact. I also compared with the other working PC, they are exactly the same, no change at all.
        If all the .dll (and all their dependencies) are correctly in the path, then its a permissions problem.