Re: Building cpan module that links with proprietary libs

["Larry Hall (Cygwin)" <reply-to-list-only-lh@cygwin.com>]

On 05/29/2014 10:36 PM, Andrew DeFaria wrote:
> 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.

Ah, I see.  A circuitous route leading to a dead-end which wasn't obvious at
the start.  Been there, done that.


<snip>

>> As aresult, 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...'

That's certainly easiest if you're willing to wait.  Otherwise, you don't
need their source code to build a C API that uses their library.  You just
need their DLLs and header files, which it sounds like you already have.
Of course if I'm wrong about that, then you don't have an option AFAICS.


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