Re: Building cpan module that links with proprietary libs
On 5/30/2014 1:01 AM, Csaba Raduly wrote: On Fri, May 30, 2014 at 4:36 AM, Andrew DeFaria wrote: On 5/29/2014 6:42 PM, Larry Hall (Cygwin) wrote: 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: Would this work? I think MSVC produces obj and lib files in COFF; can Cygwin's toolchain understand that? 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...' Maybe you can convince them to build a Cygwin version (not very likely). I am in contact with Perforce about this. They think it's a wonderful idea and they fully want me to let them know when I've managed to accomplish this! ;-) Needless to say, Cygwin, it's Perl and having a P4Perl available for it is not necessarily in Perforce's business model. Most people just use ActiveState. That said, with 5.18 I hear the backend moves to gcc and they need to address that issue. Once addressed having a Cygwin version may be easier for them to produce. I, unfortunately, do not have a lot of time to dedicate to this as my client wants me to work on others things. Using Cygwin's Perl is a convenience for me but not a necessity, though I would love to have this working. -- 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
Re: Building cpan module that links with proprietary libs
On 05/30/2014 04:01 AM, Csaba Raduly wrote: On Fri, May 30, 2014 at 4:36 AM, Andrew DeFaria wrote: On 5/29/2014 6:42 PM, Larry Hall (Cygwin) wrote: 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: Would this work? I think MSVC produces obj and lib files in COFF; can Cygwin's toolchain understand that? What I'm suggesting is not all that different than using Windows native platform or other libraries with Cygwin. So yes, what I'm suggesting will work and is the typical approach taken to use C++ libraries built by a different compiler. It's a pain but it works. In this case, you just have to wrap the class methods you want to use in C functions, declare then 'extern "C"', __cdecl, and __declspec(dllexport) (if you decide to make your "library" a DLL). Build that with VS and include the .lib at the end of your invocation of 'gcc'. Simple. :-) -- 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
Re: Building cpan module that links with proprietary libs
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. 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
Re: Building cpan module that links with proprietary libs
On Fri, May 30, 2014 at 4:36 AM, Andrew DeFaria wrote: > On 5/29/2014 6:42 PM, Larry Hall (Cygwin) wrote: >> 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: Would this work? I think MSVC produces obj and lib files in COFF; can Cygwin's toolchain understand that? > > 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...' Maybe you can convince them to build a Cygwin version (not very likely). Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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
Re: Building cpan module that links with proprietary libs
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
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:
Re: Building cpan module that links with proprietary libs
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. Then I switched to the Windows archive that contained the .lib files. 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. Thanks for your help. -- Andrew DeFaria http://defaria.com p4actionmerge.o: b .bss d .data p .pdata r .rdata r .rdata$.refptr._ZN6StrBuf10nullStrBufE r .rdata$zzz R .refptr._ZN6StrBuf10nullStrBufE t .text r .xdata U Perl_newSVpv U _Unwind_Resume 0350 T P4ActionMergeData::GetMergeHint() 0080 T P4ActionMergeData::GetMergeInfo() 0140 T P4ActionMergeData::GetYourAction() 0090 T P4ActionMergeData::GetMergeAction() 01f0 T P4ActionMergeData::GetTheirAction() 02a0 T P4ActionMergeData::GetType() 0380 T P4ActionMergeData::GetString() T P4ActionMergeData::P4ActionMergeData(ClientUser*, ClientResolveA*, StrPtr&, sv*) T P4ActionMergeData::P4ActionMergeData(ClientUser*, ClientResolveA*, StrPtr&, sv*) U StrBuf::nullStrBuf U StrBuf::Append(StrPtr const*) U StrBuf::Append(char const*) U Error::Fmt(StrBuf&, int) const U operator delete[](void*) U __gxx_personality_seh0 U __imp_PL_thr_key
Re: Building cpan module that links with proprietary libs
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. > 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. What does the following say? nm lib/libp4.a | c++filt > 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. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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
