the following patch (to the created file I know, sorry short of time)
corrects a recent regression, related to libtol tags I think, that
prevents libtool using auto-import in some cases.
Cheers,
Rob
--- libtool.m4.old Sun Mar 17 16:06:04 2002
+++ libtool.m4 Sun Mar 17 16:06:13 2002
@@ -25
> -Original Message-
> From: Stephano Mariani [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 17, 2002 10:14 AM
> To: Robert Collins; 'Gerrit P. Haase'; 'Lapo Luchini'
> Cc: [EMAIL PROTECTED]
> Subject: RE: RFP: UPX (Was Re: reducing binary distribution
> size with UPX)
>
>
> I neve
I never intended to imply that the packages should be distributed
compressed, but perhaps UPX functionality could (in the distant not so
near future) be integrated into setup, such that the installed files
could be compressed at the users discretion based on its size. :)
Stephano Mariani
> -
> -Original Message-
> From: Stephano Mariani [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 17, 2002 6:30 AM
> To: 'Gerrit P. Haase'; 'Lapo Luchini'
> Cc: [EMAIL PROTECTED]
> Subject: RE: RFP: UPX (Was Re: reducing binary distribution
> size with UPX)
>
>
> Hi!
>
> I have used UP
I'll second that.
cheers,
-Matt Smith
> I'm finding that common tasks like configure sometimes depend on
> "more", which we don't have. I can make it work by "ln -s /usr/bin/more
> /usr/bin/less". I suppose the related info files should likely be done
> also(?).
> I propose putti
I'm finding that common tasks like configure sometimes depend on
"more", which we don't have. I can make it work by "ln -s /usr/bin/more
/usr/bin/less". I suppose the related info files should likely be done
also(?).
I propose putting that link in the delivery tarball (wherever l
Hi!
I have used UPX a lot recently, and have found it very useful; however,
I would not recommend compressing all binaries with it. Instead, to get
a good compromise between size and speed, why not just compress those
files that are the least used, and/or largest.
For example, on my system, the
Hallo Lapo,
Am 2002-03-16 um 12:16 schriebst du:
>> We should not precompress delivered binaries (besides setup.exe maybe?).
>> It will not reduce the size of the packages very much.
> We could maybe include in the UPX file also two shell scripts: compress everything
> and decompress everything
> We should not precompress delivered binaries (besides setup.exe maybe?).
> It will not reduce the size of the packages very much.
We could maybe include in the UPX file also two shell scripts: compress everything
and decompress everything, just to ease things to users.
--
Lapo 'Raist' Luchini
Hallo,
Is someone willing to maintain NASM, the netwide assembler?
Gerrit
--
=^..^=
Hallo Christopher,
Am 2002-03-15 um 17:52 schriebst du:
> I think this is a useful addition to the cygwin packages but I don't see
> why it should be a requirement that it be available as a package before
> people start using it.
So we can also use NASM to build UCL/UPX which is needed here AFA
Hallo Christopher,
Am 2002-03-15 um 17:52 schriebst du:
>>UPX is quite cross-platform: you can use win32 version to package lonux
>>a.out such as linux verison to package win32 PE.
>>Moreover an UPX-compressed EXE is completely self-sufficient from UPX
>>itself, has no memory overhead and decomp
Hallo Christopher,
Am 2002-03-15 um 17:55 schriebst du:
>>Not that i'm against inclusion of upx to cygwin distro -- it's a
>>normal package like many others after all, but i really don't
>>understand why somebody would want to use such a program.
> Excellent points. This is, IMO, an argument a
Hallo Earnie,
Am 2002-03-15 um 14:28 schriebst du:
> Robert Collins wrote:
>>
>> > -Original Message-
>> > From: Lapo Luchini [mailto:[EMAIL PROTECTED]]
>> > Sent: Friday, March 15, 2002 11:48 PM
>>
>> > But if a cygwin
>> > native version is needed nonetheless I could volunteer to pac
14 matches
Mail list logo
