|
in reply to How do you compile PerlIO::gzip for AS Perl 5.10?
It builds without incident for me using ActivePerl with mingw/dmake - hard to believe that there's not a ppm package available for it at the AS repo, but I couldn't find one there either.
If you already have mingw/dmake installed, it should build fine for you, too. What errors do you get ?
If you don't already have mingw/dmake you can remedy that with
ppm install MinGW
If all else fails, I could send you a ppm package for it (if you /msg me an email address that will accept an email with a tar.gz attachment).
Cheers,
Rob
UPDATE: Looks like it's not building for some because libz (which is found by default on my machine) is unlocatable. Once that's taken care of, it should build fine. |
Re^2: How do you compile PerlIO::gzip for AS Perl 5.10?
by BrowserUk (Patriarch) on Sep 24, 2010 at 23:21 UTC
|
If all else fails, I could send you a ppm package for it
Is there anything to stop people uploading PPMs to CPAN?
I've built many modules for x64 that aren't available on any existing repository that I'm aware of, but I don't run a website, so I have nowhere to make them available.
CPAN seems like an obvious choice, but it would be better if wherever they were acted as a repository rather than just a file-store, and I can't see that happening.
Or maybe AS could find a place for user-built PPMs--with appropriate disclaimers of course.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Is there anything to stop people uploading PPMs to CPAN?
I don't know. What would the PAUSE server and indexer make of a ppm package ?
Is there a way of just sticking a file on CPAN such that PAUSE doesn't try to do the things it does when a source tarball is uploaded ?
Even if it could be done, I wouldn't. I regard CPAN as a source repository, and would consider that I had "breached faith" if I started putting binaries there. (Yeah, I know ... it's a rather fuddy-duddy antiquated reason, and not a very good one. Btw, I've no objection to someone else putting Windows binaries on CPAN - it's just something that I myself am not currently prepared to do, even if it is possible.)
Besides, I already have access to the Uwinnipeg repo - so I could stick it on there if I wanted to. But as (my perception of) my access to that repo isn't one of "anything goes, open slather", I don't usually put anything there unless:
a) it's difficult/tedious to build, and
b) I'm prepared to update it regularly.
I must admit that there are some modules that I've placed on the Uwinnipeg repo that don't get updated as regularly as they should :-) ... but that's no reason to add to the list.
Of course, offering to email a ppm package is a long way from the ideal situation - especially when someone digs up the offer 6 months down the track, by which time the package has been lost and needs to be re-built (as has happened to me more than once).
It would certainly be good if there was some place to which we could just upload ppm packages willy-nilly.
Cheers,
Rob
| [reply] |
|
|
| [reply] |
|
|
Is there anything to stop people uploading PPMs to CPAN?
The thing that would make me think twice is what are the license implications of distributing a binary - even if there is no statically linked runtime. FOSS licenses have become so complex that I no longer understand them (to tell the truth I probably never did).
If I use a Microsoft compiler then all bets are off - it's safer not to. Not sure how ActiveState get around that one. Anyone from AS wish to comment?
To be honest though, what people would really like (on Windows) is a .msi file. Many Python modules are available that way, and Rakudo is as well. Any reason why we don't do that with Perl 5 modules?
| [reply] |
|
|
Seems to me that provided the source is freely available, the fact that the packages are, for convenience, also available in binary form, is irrelevant. And if it isn't that way, it should be, and the licensing needs fixing.
I see no advantage to an .msi over a .ppm. Nor have I ever seen anyone ask for one.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Personally, I like PPM's current incarnation just fine and see no need for Windows Perl modules to be distrubuted as .msi's. But that's just me. I can definitely see some people, especially Windows admin types wanting to handle Perl module installation that same way the do all other software on their system, with .msi files.
--DrWhy
"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."
| [reply] |
|
|
| [reply] |
Re^2: How do you compile PerlIO::gzip for AS Perl 5.10?
by DrWhy (Chaplain) on Sep 28, 2010 at 21:27 UTC
|
What version of libz are you using? I tried the one out of my cygwin install, but get this at the end:
C:\Perl5.10\cpan\build\PerlIO-gzip-0.18-dz4dHj>nmake
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
gcc -c -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_F
+CRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTE
+XT -DPERL_I
MPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DHASATTRIBUTE -fno-str
+ict-aliasing -O2 -DVERSION=\"0.18\" -DXS_VERSION=\"0.18\" "-IC:\
+Perl5.10\li
b\CORE" -DLAYERGZIP_DEFAULT_OS_TYPE=11 gzip.c
Running Mkbootstrap for PerlIO::gzip ()
C:\Perl5.10\bin\perl.exe -MExtUtils::Command -e chmod 644 gzip
+.bs
C:\Perl5.10\bin\perl.exe -MExtUtils::Mksymlists -e "Mksymlist
+s('NAME'=>\"PerlIO::gzip\", 'DLBASE' => 'gzip', 'DL_FUNCS' => { }, '
+FUNCLIST' =
> [], 'IMPORTS' => { }, 'DL_VARS' => []);"
dlltool --def gzip.def --output-exp dll.exp
g++ -o blib\arch\auto\PerlIO\gzip\gzip.dll -Wl,--base-file -Wl
+,dll.base -mdll -L"C:\Perl5.10\lib\CORE" gzip.o -Wl,--image-base,0x49
+1e0000 C:\
Perl5.10\lib\CORE\perl510.lib -lkernel32 -luser32 -lgdi32 -lwinspool -
+lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -
+lws2_32 -lm
pr -lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt dll.exp
gzip.o:gzip.c:(.text+0x4fe): undefined reference to `inflateInit2_'
gzip.o:gzip.c:(.text+0x5b7): undefined reference to `crc32'
gzip.o:gzip.c:(.text+0xac0): undefined reference to `deflateInit2_'
gzip.o:gzip.c:(.text+0xafe): undefined reference to `crc32'
gzip.o:gzip.c:(.text+0xf3d): undefined reference to `crc32'
gzip.o:gzip.c:(.text+0xfed): undefined reference to `inflateEnd'
gzip.o:gzip.c:(.text+0x101d): undefined reference to `deflateEnd'
gzip.o:gzip.c:(.text+0x12c5): undefined reference to `inflate'
gzip.o:gzip.c:(.text+0x13d2): undefined reference to `crc32'
gzip.o:gzip.c:(.text+0x14ba): undefined reference to `deflate'
gzip.o:gzip.c:(.text+0x1618): undefined reference to `crc32'
collect2: ld returned 1 exit status
NMAKE : fatal error U1077: 'C:\Perl5.10\site\bin\g++.EXE' : return cod
+e '0x1'
Stop.
Update: In the example above I used nmake. However, afterwards, I reconfigured my system to use dmake instead and got the same result.
Update/Solution: I found that using the MSYS zlib-dev distribution finally worked. http://sourceforge.net/projects/mingw/files/MSYS/zlib/zlib-1.2.3-2/zlib-1.2.3-2-msys-1.0.13-dev.tar.lzma/download. This delivers a set of two directories, include and lib, which contain resp. headers and precompiled library files. The other trick that I had to do to make this work was that the lib files had to be placed in the <Perl5.10>\lib\CORE directory.
--DrWhy
"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."
| [reply]
[d/l] |
|
|
