Building cpan module that links with proprietary libs

[Larry Hall (Cygwin)]

On 05/29/2014 01:48 PM, Andrew DeFaria wrote:
> On 5/29/2014 1:29 AM, Csaba Raduly wrote:
>> Hi Andrew,
>>
>> On Thu, May 29, 2014 at 4:12 AM, Andrew DeFaria  wrote:
>>> 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).
>>
>> The C++ P4 API is platform-specific; which platform did you choose?
>> If it really contains .lib files (not .a), those are not recognized by
>> Cygwin's gcc.
>
> I had two archives two choose from. One was for Windows and contained the
> .lib files. The other was for Linux and contains .a files. I first tried the
> Linux one but that failed with:
>
> 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
> -L/cygdrive/a/p4perlBuild/p4api/lib -lclient -lrpc -lsupp -lp4sslstub        \
>
> collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
> Makefile:531: recipe for target 'blib/arch/auto/P4/P4.dll' failed
> make: *** [blib/arch/auto/P4/P4.dll] Error 1
> Adefaria-lt:
>
> I can give you more output if you need it.

No need.  Forgive me for saying this but I find it hard to believe that
after all this time on the list Andrew that you don't know that trying to
use Linux-compiled libraries on Cygwin isn't going to work.  But I guess
my surprise is not that important here. ;-)

> Then I switched to the Windows archive that contained the .lib files.

Sensible but...

> I think the issue is that their Windows P4Perl build system uses Visual
> Studio to build and on Linux it uses g++. Their installation package is only
> for ActiveState. Supposedly at 5.18 ActiveState is changing to a g++ based
> backend using MingW I think so they'll eventually have to figure this out.
> Meantime I'm just trying to get it working under Cygwin's Perl...
>
>>> 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!
>>
>> No it doesn't. The argument to -o is blib/arch/auto/P4/P4.dll
>> lib/libp4.a is the next input file.
>
> Good catch! I missed that.
>
>  > What does the following say?
>>
>> nm lib/libp4.a | c++filt
>
> Attached.
>
>>> 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.
>>
>> It seems to be on the right track; "g++ -shared -o P4.dll" sounds good to me.

You say that the libs were built by Visual Studio and the remainder of your
comments make it clear that the libraries are C++ and not C code.  As a
result, you will never get code compiled with g++ to link with these
libraries.  There is no common ABI among C++ compilers.  Thus, the libraries
and headers of one can't be used as input to the compiler of another, even
on the same platform.  This only works for C code.  So you have to either
build the proprietary libs with Cygwin's C++ compiler or write your own
"shim" library that wraps the necessary calls and objects in a C API,
compile that with VS, and link your program against the APIs in your
library.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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