Building cpan module that links with proprietary libs

[Andrew DeFaria]

I'm attempting to build a cpan module (well actually it's not a cpan 
module but rather a module that uses MakeMaker and has the familiar perl 
Makefile.PL, make, make test, make install installation procedure. 
Additionally I need to link it to a set of proprietary libs that I am 
given only the .lib files for. If you must know this is for Perforce's 
P4Perl which I'd like to get working with Cygwin's Perl natively.

I download the P4API bundle (the package that has include files and the 
.lib files pre-compiled). Next I need to do:

$ perl Makefile.PL --api-dir /.../path/to/unzipped/p4api

This works fine and I procedure with the make. This fails with things like:

make[1]: Leaving directory '/cygdrive/a/perl/P4Perl.Cygwin/lib'
g++ -c  -I/cygdrive/a/perl/p4api.windows/include/p4 -Ilib -x c++ 
-DUSEIMPORTLIB -O3   -DVERSION=\"2014.1\" -DXS_VERSION=\"2014.1\" 
"-I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE" 
-DID_OS="\"CYGWIN17THREAD\"" -DID_REL="\"2014.1\"" 
-DID_PATCH="\"842847\"" -DID_Y="\"2014\"" -DID_M="\"05\"" 
-DID_D="\"06\"" -DOS_CYGWIN -DOS_CYGWIN17 -DOS_CYGWIN17THREAD 
-DOS_CYGWINTHREAD -DP4API_VERSION="515585" -DID_API="\"2014.1/821990\"" P4.c
Running Mkbootstrap for P4 ()
chmod 644 P4.bs
rm -f blib/arch/auto/P4/P4.dll
g++  -shared P4.o  -o blib/arch/auto/P4/P4.dll lib/libp4.a      \
   /usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE/cygperl5_14.dll        \

P4.o:P4.c:(.text+0x45ac): undefined reference to 
`ClientApi::SetClient(char const*)'
P4.o:P4.c:(.text+0x45ac): relocation truncated to fit: R_X86_64_PC32 
against undefined symbol `ClientApi::SetClient(char const*)'
P4.o:P4.c:(.text+0x4a9c): undefined reference to 
`ClientApi::SetHost(char const*)'

Notice that it removes P4.dll, so it seems to know it's working with 
dll's, but then it calls g++ with a -o for libp4.a! Why a .a? Shouldn't 
this be .dll?

Meantime it fails with many undefined references. I think I might need 
to do perl Makefile.PL with other opts to tell it that while it's using 
Cygwin and can be very Linux-like, it needs to produce .dll's and not 
.a's or .o's.

Has anybody managed to do this? What am I doing wrong?
-- 
Andrew DeFaria
http://defaria.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple