RE: problem building latest perl (24978) on win32
From: Dave Mitchell [mailto:[EMAIL PROTECTED] On Fri, Jul 08, 2005 at 08:03:55PM +0100, Nick Ing-Simmons wrote: But if Compress::Zlib links to private zlib code or libz.a then there are two copies of code and associated symbols in the application and that can cause confusion at best and bugs at worst. Also, given that there's just been a new security vunerability in zlib, I'll post an update to Compress::Zlib this week -- zlib 1.2.3 has just been released to fix the security issue. linking in an old private copy rather than using the OS's version, doesn't sound like the best of policies As opposed to linking in the OS's even older shared copy :-) Ironically, one of the reasons I included a private copy of the zlib source was to allow Compress::Zlib to easily have access to a newer version of zlib than is shipped with some operating systems -- Solaris 2.8, for example, ships with zlib 1.1.4. This, of course, can be argued both ways, but with Compress::Zlib in the core, there is now a lot more scope for getting Configure to check for the presence of libz. What its does when the OS's copy of libz is older than the version included with Compress::Zlib is another question. Paul ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: problem building latest perl (24978) on win32
On Fri, Jul 08, 2005 at 08:03:55PM +0100, Nick Ing-Simmons wrote: But if Compress::Zlib links to private zlib code or libz.a then there are two copies of code and associated symbols in the application and that can cause confusion at best and bugs at worst. Also, given that there's just been a new security vunerability in zlib, linking in an old private copy rather than using the OS's version, doesn't sound like the best of policies -- A walk of a thousand miles begins with a single step... then continues for another 1,999,999 or so.
Re: problem building latest perl (24978) on win32
Rafael Garcia-Suarez [EMAIL PROTECTED] writes: On 7/5/05, Nick Ing-Simmons [EMAIL PROTECTED] wrote: Probing for existing libz (shared or not) would help those of us the embed perl in other things which already link zlib. But IIUC zlib is embedded in a shared extension, not in perl itself. Compress::Zlib is a perl extension. It is linked against libz.a/libz.so on UNIX or zlib.lib/zlib.dll on Win32. If the application which embeds perl _already_ links to libz.so then when Compress::Zlib is loaded into the embedded perl there are two copies of libz.so (or zlib.dll) referenced and that is harmless (except on old BSD SunOS4). But if Compress::Zlib links to private zlib code or libz.a then there are two copies of code and associated symbols in the application and that can cause confusion at best and bugs at worst.
Re: problem building latest perl (24978) on win32
On 7/5/05, Nick Ing-Simmons [EMAIL PROTECTED] wrote: Probing for existing libz (shared or not) would help those of us the embed perl in other things which already link zlib. But IIUC zlib is embedded in a shared extension, not in perl itself.
RE: problem building latest perl (24978) on win32
Probing for existing libz (shared or not) would help those of us the embed perl in other things which already link zlib. But IIUC zlib is embedded in a shared extension, not in perl itself. files inside ./ext/Compress/Zlib/zlib-src-1.2.2 are zlib itself. So if you're linking all things together with another application already having zlib, you'll duplicate code. And the question, as I understand it, is to make functions from that zlib (inside perl) to be exportable to other apps. From my own experience, it is quite okay to link zlib so not only Perl, but other applications have it available. Vadim.
Re: problem building latest perl (24978) on win32
Nicholas Clark [EMAIL PROTECTED] writes: On Sat, Jun 25, 2005 at 07:59:40PM -0400, vadim wrote: BTW, given that Compress::Zlib is now in the core (which is a good thing IMO) is it possible to export zlib functions also, so to reuse code when linking with other software requiring it? I can't really answer that. Would we get the same effect by having Configure probe for a shared libz and Compress::Zlib use that if found? I'm assuming that you'd install a shared libz before building perl for this to work out. Probing for existing libz (shared or not) would help those of us the embed perl in other things which already link zlib.
problem building latest perl (24978) on win32
Dear all, when building with ITHREADS, MULTIPLICITY, IMP_SYS turned off, and PERL_MALLOC, PERLIO turned on, following linker error happens: link -dll -def:perldll.def -base:0x2800 -out:..\perl59.dll @[EMAIL PROTECTED]:\Temp\nmb00668.^M perldll.def : error LNK2001: unresolved external symbol PL_dumper_fd^M ..\perl59.lib : fatal error LNK1120: 1 unresolved externals^M LINK : fatal error LNK1141: failure during build of exports file^M NMAKE : fatal error U1077: 'link' : return code '0x475'^M Stop.^M (miniperl is built okay) could you please anyone advice how this should be fixed? TIA. Vadim.
Re: problem building latest perl (24978) on win32
On Sat, Jun 25, 2005 at 06:05:31PM -0400, vadim wrote:
Dear all,
when building with ITHREADS, MULTIPLICITY, IMP_SYS turned off, and
PERL_MALLOC, PERLIO turned on, following linker error happens:
link -dll -def:perldll.def -base:0x2800 -out:..\perl59.dll
@[EMAIL PROTECTED]:\Temp\nmb00668.^M
perldll.def : error LNK2001: unresolved external symbol PL_dumper_fd^M
..\perl59.lib : fatal error LNK1120: 1 unresolved externals^M
LINK : fatal error LNK1141: failure during build of exports file^M
NMAKE : fatal error U1077: 'link' : return code '0x475'^M
Stop.^M
(miniperl is built okay)
could you please anyone advice how this should be fixed?
Aargh. Can anyone figure out a way to automate this? I think adding
this to makedef.pl will do it:
unless ($define{'DEBUG_LEAKING_SCALARS_FORK_DUMP'}) {
skip_symbols [qw(
PL_dumper_fd
)];
}
Does this fix it?
Nicholas Clark
Re: problem building latest perl (24978) on win32
Aargh. Can anyone figure out a way to automate this? I think adding
this to makedef.pl will do it:
unless ($define{'DEBUG_LEAKING_SCALARS_FORK_DUMP'}) {
skip_symbols [qw(
PL_dumper_fd
)];
}
Does this fix it?
yes, that error gone...
thanks for quick responce.
BTW, given that Compress::Zlib is now in the core (which is a good thing
IMO) is it possible to export zlib functions also, so to reuse code
when linking with other software requiring it?
Vadim.
Re: problem building latest perl (24978) on win32
On Sat, Jun 25, 2005 at 07:59:40PM -0400, vadim wrote: BTW, given that Compress::Zlib is now in the core (which is a good thing IMO) is it possible to export zlib functions also, so to reuse code when linking with other software requiring it? I can't really answer that. Would we get the same effect by having Configure probe for a shared libz and Compress::Zlib use that if found? I'm assuming that you'd install a shared libz before building perl for this to work out. Nicholas Clark
Re: problem building latest perl (24978) on win32
В Сбт, 25.06.2005, в 12:19, Nicholas Clark пишет: On Sat, Jun 25, 2005 at 07:59:40PM -0400, vadim wrote: BTW, given that Compress::Zlib is now in the core (which is a good thing IMO) is it possible to export zlib functions also, so to reuse code when linking with other software requiring it? I can't really answer that. Would we get the same effect by having Configure probe for a shared libz and Compress::Zlib use that if found? I'm assuming that you'd install a shared libz before building perl for this to work out. no no no... Compress::Zlib (inside perl distribution) currently includes entire zlib library, and it is certainly should be found. But don't worry, I'll probably check for myself for reusing 'zlib'. Vadim.
