This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building cpan module that links with proprietary libs


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]