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