Building cpan module that links with proprietary libs

Fri May 30 08:01:00 GMT 2014

On 5/29/2014 6:42 PM, Larry Hall (Cygwin) wrote:
>> 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. ;-)

When I first when to get this to work I choose the Linux style of the 
package for p4api. I figured the Windows style was for ActiveState only 
and that'd probably not work. Hell ActiveState doesn't even use cpan, 
they use ppm. I didn't look inside for anything like .o, .a or .dll or 
.lib. I figured that it would have been source code and it would have 
been compiled as part of the make process. It wasn't until it failed 
that I saw the reference to .a's, etc. and looked into the p4api 
directory structure to see .lib's in the Windows copy and .a's in the 
Linux copy. Sure at *that* point I knew the Linux style will never work 
in this situation. So I tried to link with the Windows style .lib copy.
>>> 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.

I don't believe I ever said it was just C code. If I did then I'm sorry.
> 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.

Being as this code is proprietary I doubt that Perforce will release it 
to me to compile but I will point them at this thread...'
Thanks.
-- 
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