Re: Building cpan module that links with proprietary libs

[Andrew DeFaria <Andrew at DeFaria dot com>]

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