Chunmei Wu wrote:
> Hi Martin,
> 
> unixus...@dsliaa05 # >  perl -MExtUtils::MakeMaker -le 'print 
> $ExtUtils::MakeMaker::VERSION;'
> 6.03

NO_META was added to ExtUtils::MakeMaker in 6.10 so I've fix that to
only use it if >= 6.10. BTW, 6.03 is a VERY old version of
ExtUtils::MakeMaker (June 2002). If you are going to be building modules
a lot of this machine I'd expect you might start running up against
other problems if all your modules are this old and you try and use some
of the latest modules.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

> Ok. I will rebuild my perl to version 64 and try again.
> 
> Thanks,
> Chunmei Wu
> 
> 
> -----Original Message-----
> From: Martin Evans [mailto:martin.ev...@easysoft.com] 
> Sent: 2010年5月10日 16:32
> To: Chunmei Wu
> Cc: dbi-users@perl.org
> Subject: Re: make test: dlopen error :can't load library ODBC.so
> 
> Chunmei Wu wrote:
>> Hi Martin, Reinhard and Jens,
>>
>> Thanks for your advice. Following is related info you referred:
>>
>> 1> Are all the components in your chain (perl, driver manager, driver) all64 
>> bit? 
>> [Chunmei]: The unixODBC driver and the DB2 driver are 64bit. Seems that my 
>> perl is 32bit from following info. Is this the reason for my error????
>>      unixus...@dsliaa05 # > file perl
>>      perl: executable (RISC System/6000) or object module
> 
> Probably. You need to match the build type from Perl all the way down to
> the driver.
> 
>> 2> What does perl -V output?
>> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
> 
> 32bit build of Perl
> 
> <snipped perl -V output>
> 
>> 3> What ODBC driver manager are you using?
>> [Chunmei]: UnixODBC 2.3.0
> 
> Good, that's ok.
> 
>> 4> I think it could be helpful (if no one else has a better proposal) to 
>> start fresh and record the entire make output in a file
>> [Chunmei]: I did it, but I didn't get any error when run 'make':
>>     a) perl Makefile.PL
>>      Warning: LD_LIBRARY_PATH doesn't include 
>> /home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/
>>      [Chunmei]: the warning is strange. Even I set this environment to 
>> include this directory, it still report such warning. Meanwhile, I think AIX 
>> didn't use this environment but LIBPATH.
> 
> You are correct. It is an old hang up the Makefile.PL from ages ago.
> I may try and remove that warning.
> 
>>      WARNING: NO_META is not a known parameter.
> 
> What version of ExtUtils::MakeMaker are you using?
> 
> e.g.,
> 
> $ perl -MExtUtils::MakeMaker -le 'print $ExtUtils::MakeMaker::VERSION;'
> 6.42
> 
> 
>>      b) make
>>      NO warning.
>>      c) make test
>>      The error 'can't load library...' occur.
> 
> I think we've diagnosed 32/64 bit mismatch.
> 
> You need to rebuild Perl 64bit or rebuild unixODBC 32bit and get a 32bit
> version of your ODBC driver.
> 
>> 5> Looks to me like libperl.a is missing from the requirements list of 
>> ODBC.so. As long you don't have statically linked the perl runtime, this 
>> could be an issue.
>> [Chunmei]: Following command is used to create ODBC.so:
>> LD_RUN_PATH="/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib"
>>  ld  -bhalt:4 -bM:SRE 
>> -bI:/vobs/vob_src_3rdparty/src/3rdparty/perl2exe/aix/perl2exe/perl5.8/lib/5.8.0/aix/CORE/perl.exp
>>  -bE:ODBC.exp -bnoentry -lC -lc ConvertUTF.o ODBC.o dbdimp.o 
>> unicode_helper.o  -o blib/arch/auto/DBD/ODBC/ODBC.so   
>> -L/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64/lib -lodbc
>>
>> No error reports during the build and the ldd also is ok. 
>>
>> 6> Maybe it is only a question of dynamic loaded libraries not included in 
>> the search path. If I remember well there is a LD_LIBRARY_PATH variable you 
>> can add locations where to search libraries to be loaded when executing the 
>> program.
>> [Chunmei]: AIX uses LIBPATH instead of LD_LIBRARY_PATH to search libraries. 
>> The value of $LIBPATH is 
>> "/home/eng-sm/unixuser/claire/test/perl/unixodbc_install2.3.0_64//lib:/usr/lib:/lib:/opt/IBM/db2/V9.7/lib64"
>>  in my environment.
>>
>> Thanks,
>> Chunmei Wu
> 
> BTW, I redirected this back to the dbi-users list as it is not
> appropriate to dbi-dev.
> 
> Martin

Reply via email to