Re: GCC 4.1 now the default GCC version for etch
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Falk Hueffner <[EMAIL PROTECTED]> writes: >> On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: >>> Falk Hueffner <[EMAIL PROTECTED]> writes: >>> > So in summary, if you don't care about portability to 64-bit windows, >>> > assuming sizeof(void*) == sizeof(long) is just fine. >>> >>> Unless you compile with range checking pointers. >> >> The current implementation of range checking in gcc (mudflap) uses >> normal-sized pointers. > > Even in 32bit? How do they cram all that info in there? By using an object database lookup. See http://gcc.fyxm.net/summit/2003/mudflap.pdf -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: > Falk Hueffner <[EMAIL PROTECTED]> writes: > > So in summary, if you don't care about portability to 64-bit windows, > > assuming sizeof(void*) == sizeof(long) is just fine. > > Unless you compile with range checking pointers. The current implementation of range checking in gcc (mudflap) uses normal-sized pointers. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Fri, Jun 16, 2006 at 07:06:06PM -0500, Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Falk Hueffner wrote: > > On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > >> long is not appropriate to save pointers, you need to use intptr_t or > >> uintptr_t. > > > > C90 basically promised it would work, and it is widely considered a > > bug in C99 that there is no such guarantee. sizeof(void*) == > > sizeof(long) is also assumed all over the place in Linux, and there is > > "Linux == kernel" or "Linux == distro"? Both. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Fri, Jun 16, 2006 at 02:39:26PM -0700, Philip Brown wrote: > On Fri, Jun 16, 2006 at 11:15:32PM +0200, Falk Hueffner wrote: > > Henning Makholm wrote: > > > > > Another related bug type that I found lurking in my packages when I > > > investigated the warnings in this list, is trying to format a size_t > > > value with a %u or %d format string > > > > Since any sane ABI pads arguments to word size, this is only a problem > > on big endian 64-bit architectures (that is, no current release > > architecture). > > So to deliberately ignore an issue, becuase > "we dont support big-endian 64bit *right now*", would seem to be rather > short sighted to me. I didn't suggest to ignore the issue. I'm just providing information to help people to prioritize. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Henning Makholm wrote: > Another related bug type that I found lurking in my packages when I > investigated the warnings in this list, is trying to format a size_t > value with a %u or %d format string, which will break if size_t is 64 > bits (unless the actual number is small and it is the last argument > and the endianness of the architecture happens to match its stack > growth direction). Since any sane ABI pads arguments to word size, this is only a problem on big endian 64-bit architectures (that is, no current release architecture). -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: > > The others are trivially fixable; of these, the one in libavcodec is already > > fixed in CVS. I've committed the rest (they're basically s/int/long/) and am > > forwarding them appropriately. > > long is not appropriate to save pointers, you need to use intptr_t or > uintptr_t. C90 basically promised it would work, and it is widely considered a bug in C99 that there is no such guarantee. sizeof(void*) == sizeof(long) is also assumed all over the place in Linux, and there is not a chance in hell that will ever change. The only relevant system that does not have sizeof(void*) == sizeof(long) is 64-bit windows. So in summary, if you don't care about portability to 64-bit windows, assuming sizeof(void*) == sizeof(long) is just fine. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc built with gcc-4.1 (update)
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Falk Hueffner a écrit :
>> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>>
>>>On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
>> On Alpha the problem is:
>> {standard input}: Assembler messages:
>> {standard input}:341: Error: macro requires $at register while noat in effect
>> {standard input}:374: Error: macro requires $at register while noat in effect
>> {standard input}:438: Error: macro requires $at register while noat in effect
>> {standard input}:471: Error: macro requires $at register while noat in effect
>> make[3]: *** [/tmp/buildd/glibc-2.3.6/build-tree/alpha-libc/misc/ioperm.o]
>> Error 1
>> Hrm. gcc puts .arch ev4 into the .s, and this overrides -mev6 for as.
>> I cannot really think of anything better than
>
> Ok, thanks a lot, I will add it in the SVN soon.
>
> Do you think it is a fix or a workaround? Or rather do you think this
> behaviour is correct?
Well, the right thing to do would be to turn arch to ev6, and then
restore it to whatever it was previously; with this patch, it remains
turned on for the rest of the file and could potentially hide errors.
However, I don't think that's possible with gas. So given this
deficiency, I don't think there's a better way.
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc built with gcc-4.1 (update)
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> On arm, ia64 and alpha the glibc fails to build with gcc-4.1.
On Alpha the problem is:
{standard input}: Assembler messages:
{standard input}:341: Error: macro requires $at register while noat in effect
{standard input}:374: Error: macro requires $at register while noat in effect
{standard input}:438: Error: macro requires $at register while noat in effect
{standard input}:471: Error: macro requires $at register while noat in effect
make[3]: *** [/tmp/buildd/glibc-2.3.6/build-tree/alpha-libc/misc/ioperm.o]
Error 1
Hrm. gcc puts .arch ev4 into the .s, and this overrides -mev6 for as.
I cannot really think of anything better than
--- ioperm.c~ 2001-07-06 06:56:13.0 +0200
+++ ioperm.c2006-05-30 21:22:54.0 +0200
@@ -173,13 +173,13 @@
static inline void
stb_mb(unsigned char val, unsigned long addr)
{
- __asm__("stb %1,%0; mb" : "=m"(*(vucp)addr) : "r"(val));
+ __asm__(".arch ev6; stb %1,%0; mb" : "=m"(*(vucp)addr) : "r"(val));
}
static inline void
stw_mb(unsigned short val, unsigned long addr)
{
- __asm__("stw %1,%0; mb" : "=m"(*(vusp)addr) : "r"(val));
+ __asm__("".arch ev6; stw %1,%0; mb" : "=m"(*(vusp)addr) : "r"(val));
}
static inline void
@@ -351,7 +351,7 @@
unsigned long int addr = dense_port_to_cpu_addr (port);
unsigned char r;
- __asm__ ("ldbu %0,%1" : "=r"(r) : "m"(*(vucp)addr));
+ __asm__ (".arch ev6; ldbu %0,%1" : "=r"(r) : "m"(*(vucp)addr));
return r;
}
@@ -361,7 +361,7 @@
unsigned long int addr = dense_port_to_cpu_addr (port);
unsigned short r;
- __asm__ ("ldwu %0,%1" : "=r"(r) : "m"(*(vusp)addr));
+ __asm__ (".arch ev6; ldwu %0,%1" : "=r"(r) : "m"(*(vusp)addr));
return r;
}
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
Steve Langasek <[EMAIL PROTECTED]> writes: > On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: >> Matthew Garrett <[EMAIL PROTECTED]> writes: > >> > * the release architecture must be publicly available to buy new > >> > Avoids a situation where Debian is keeping an architecture alive. > >> I don't understand this. What is the problem with Debian is keeping an >> architecture alive? What problem are you trying to solve here? > > Given that there are architectures that have been end-of-lifed (but > *are* still available for purchase new) that we've had problems > keeping our autobuilders running for, I think it's a fair guess that > hardware that truly is no longer available for purchase is going to > be costly for the project to continue to support for a stable > release. This is too vague for me. > Aside from concerns about the availability and cost of replacement > hardware, Has this really been a problem for Debian? > it's likely that new systems will continue to be sold for some time > after the chip manufacturers stop designing new (faster, better) > chips, so such systems are not going to be keeping up with the > increase in CPU demands of compiling the archive. There's already another criterion for this, which captures this far better. > This adds up to a lot of effort for a dead-end architecture. Do you > believe that such ports are going to command enough interest to be > able to keep up with Debian's stable support requirements for more > than 2 1/2 years (18mo. release cycle + 1 year support for > oldstable) after being discontinued as a product? Given that you'll probably not be able to buy an i386 box in a few years anymore, I'd say "yes". But I see little point in trying to guess here. Ports that cannot keep up should be filtered by the other criterions. > Furthermore, do you believe that the limited resources of DSA (which > will *always* be limited, no matter how big you say you want the > team to be, because there's *always* more to do than there are > people to do it) should be spent keeping stable security buildds for > such architectures running, instead of on tasks that are useful to > users of living architectures? This is again pretty vague. You basically say that we need to drop architectures, and we should drop those that are "not living". Firstly, this particular criterion is not effective at dropping architectures: currently, all of our architectures can be bought new. Secondly, it doesn't seem like a good criterion for determining "livingness": arm, mips, and m68k are basically immune to this for the next 10 years or so, since they are used in embedded systems and can be produced very cheaply. I already mentioned i386 as a contrast. In summary, it seems like this criterion isn't trying to solve some particular problem, but it just generally targeted towards cutting down the number of architectures. I already have doubts as to whether this is a reasonable premise, but even if I accept it, it seems neither effective nor particularly well-motivated. >> > * the value of N above must not be > 2 > >> > This effectively sets an upper limit on the length of time a single >> > package may take to build, which helps ensure that doing things like >> > security fixes for Openoffice doesn't become a problem. > >> If the point is to set an upper limit on the length of time a single >> package may take to build, why not take that directly as a criterion? > > Wouldn't this also be an arbitrary penalty on slower architectures, > though? Of course it would. But if the point is to set an upper limit on build time, that would be a good thing and not arbitrary. > Build time for a single package is also only one of the concerns; > the other big one being that it's much more likely to get security > wrong for one out of ten buildds, rather than for one out of three. What do you mean by "getting security wrong"? Can you give an example? Is there evidence that this is a problem for the architectures that currently have many buildds? -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
Matthew Garrett <[EMAIL PROTECTED]> writes: > * the release architecture must be publicly available to buy new > > Avoids a situation where Debian is keeping an architecture alive. I don't understand this. What is the problem with Debian is keeping an architecture alive? What problem are you trying to solve here? > * the value of N above must not be > 2 > > This effectively sets an upper limit on the length of time a single > package may take to build, which helps ensure that doing things like > security fixes for Openoffice doesn't become a problem. If the point is to set an upper limit on the length of time a single package may take to build, why not take that directly as a criterion? It is even more objective. It might also encourage people to split unreasonably large packages. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does this break binary compatability on 64bit architectures?
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes: >> -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result, >> +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result, >> size_t * result_len); > > That is, 'uint32_t' was changed to 'unsigned int'. > > Does this break binary compatability on any of debian architectures (so > soname change is needed)? No. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
Marcelo E. Magallon writes: > On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote: > > > > occurs when you have for example an ev56 library in lib/ev56, and a > > > ev67 CPU. Then the loader looks in lib/ev67 and then falls back to > > > lib. Since glibc is very carefully undocumented in this area [1], I > > > didn't want to try to change this, but rather assumed one could add > > > a symlink. > > > > Yes, and if ev67 is instruction upper compatible with ev56 (I guess > > so), I think it's acceptable to add a symlink "ln -sf > > lib/ev67/libfoo.so lib/ev56/libfoo.so". > > Ugh... that pushes the burden of maitaining support for new > architectures to the package. Please bear with me, but I'm trying > to understand the issue: is the cost of calling access(2) or stat(2) > really so high? I'd consider it quite acceptable in this case. However, as I tried to express, it's not possible with glibc's current "design", and I didn't feel like changing that. > I see for example that on start up the file /etc/ld.so.nohwcap is > accessed multiple times (and it's not present, isn't that a race? > what happens if the file suddenly appears in the middle of program > start up? what's that file anyway, I can't find it mentioned in the > documentation). It's supposed to disable the use of hwcaps. Stating it multiple times seems like a bug. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian-induced changes in changelog, hardlinks?
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > Also, eh, I'm not convinced lintian is correct here in complaining, > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > but is it really bad to have them? Having them across different > directories might cause problems when the user has those on different > filesystems, but in the same directory? Opinions? Some file systems don't support hardlinks, such as AFS, which causes a lot of trouble if you want to mount a Debian system via AFS. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
GOTO Masanori <[EMAIL PROTECTED]> schrieb am 13.01.05 02:01:11: > At Tue, 11 Jan 2005 11:27:28 +0100, > Falk Hueffner wrote: > > Marcelo E. Magallon <[EMAIL PROTECTED]> wrote: > > > IIRC, alpha does not define any hwcaps. > > > > There's a patch for this, which works fine, but wasn't committed yet: > > http://lists.debian.org/debian-glibc/2004/03/msg00143.html > > > > Sensible options are ev56 and ev67; ev5 is not particularly useful, since > > it has the same instruction set as the baseline ev4, only different > > scheduling. > > -mieee is default anyway on Debian's gcc. > > Yes, we don't support it currently, but I think it should be available > after sarge. > > BTW, this patch does not enable HWCAP_IMPORTANT - so the answer of > first question from Marcelo is: alpha does not support library HWCAP > directory loading even if this patch is applied. That's right. The reason is that the Alpha architecture doesn't have a set of capabilities, from which each CPU version picks a random few, but rather every CPU version is a proper superset of the preceding version. So I did not use the orthogonal HWCAP model at all. > If other libraries > like mesa and libssl want to use /usr/lib/ev67 and so on, we may > consider to add HWCAP_IMPORTANT. This should not be needed, since the library loader also looks in a directory corresponding to the architecture name. The only problem with this occurs when you have for example an ev56 library in lib/ev56, and a ev67 CPU. Then the loader looks in lib/ev67 and then falls back to lib. Since glibc is very carefully undocumented in this area [1], I didn't want to try to change this, but rather assumed one could add a symlink. Falk [1] _dl_important_hwcaps is a great text book example on how not to do comments, if anybody ever needs one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
GOTO Masanori <[EMAIL PROTECTED]> wrote: > Marcelo E. Magallon <[EMAIL PROTECTED]> wrote: >> Mesa upstream uses -mcpu=ev5 -mieee on alpha. Is that ok? Where does >> this belong into? /usr/lib/ev5? > > IIRC, alpha does not define any hwcaps. There's a patch for this, which works fine, but wasn't committed yet: http://lists.debian.org/debian-glibc/2004/03/msg00143.html Sensible options are ev56 and ev67; ev5 is not particularly useful, since it has the same instruction set as the baseline ev4, only different scheduling. -mieee is default anyway on Debian's gcc. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem
Ralf Treinen <[EMAIL PROTECTED]> writes: > > E2tools is a simple set of GPL'ed utilities to read, write, and > > manipulate files in an ext2/ext3 filesystem. > > please excuse my ignorance - what would be the advantage of these > tools over the core file utilities which use the VFS layer? You don't need root. Useful for example to build rescue floppy images. -- Falk
Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
"Benj. Mako Hill" <[EMAIL PROTECTED]> writes: > On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote: > > Package: wnpp > > Version: N/A; reported 2003-06-27 > > Severity: wishlist > > > > * Package name: email > > I understand that email is the name of the upstream client but I'd > like to urge you to reconsider keeping this name while the program is > in Debian. Fortunately, this is no problem, since the license (http://email.cleancode.org/download/COPYING) doesn't allow redistribution anyway and so it cannot even go to non-free. -- Falk
Re: Dropping/splitting (proper) i386 support
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Oddly, it looks like GCC doesn't currently ever generate > 486-specific instructions; they are only (currently) of benefit to > assembly programmers. (Hmm... maybe I should see if there's an > enhancement opportunity to GCC there.) I have a patch floating around here that adds a __builtin_bswap32/64, which could generate bswap on i486, if anybody is interested. I was planning to recognize bswaps from C Code too, but I'm not sure that will work out... I think it would be quite useful, though, since byte swapping often occurs in performance-critical code like emulators. -- Falk
Re: package pool and big Packages.gz file
Sam Vilain <[EMAIL PROTECTED]> writes: > On Fri, 5 Jan 2001 19:08:38 +0200 > [EMAIL PROTECTED] (Sami Haahtinen) wrote: > > > Or, can rsync sync binary files? > > hmm.. this sounds like something worth implementing.. > > rsync can, but the problem is with a compressed stream if you insert > or alter data early on in the stream, the data after that change is > radically different. > > But... you could use it successfully against the .tar files inside > the .deb, which are normally compressed. This would probably > require some special implementation of rsync, or to have the > uncompressed packages on the server and put the magic in apt. > > [...] > > Either that or keep a number of patch files or .xd files for a > couple of old revs per packages against the uncompressed contents of > packages to allow small changes to packages to be quick. Or perhaps > implement this as patch packages, which are a special .deb that only > contain the changed files and upgrade the package. I suggest you have a look at 'tje' by Joost Witteveen (http://joostje.op.het.net/tje/index.html). It is specifically written with the goal in mind to sync Debian mirrors with minimum bandwidth use. It doesn't use the rsync algorithm, but something similar. It understands .debs and claims to have less server CPU usage than rsync, since it caches diffs and md5sums. It would be really nice if anybody with an up-to-date mirror could volunteer to provide a machine to set up a tje server to test it a little more... Falk
Re: Debian Source distributions (was Re: Intent to package pine-src)
Brederlow <[EMAIL PROTECTED]> writes: > It would be a great idea to have source dependencies. I compile all > sources on my debian mirror and most fail because of missing > files. One then has to search the package and install that before > compiling again. A very simple way to improve in this area would be if it was allowed in the policy to add a "Depends:" line to the .dsc file with the same format as for .debs. Very easy. Developers probably would start to use it, since it makes compiling really much easier for other people. Some time in the future this field would probably be made obligatory and tools for source extraction could be extended to check them. Any opionions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and Window Mangers
Branden Robinson <[EMAIL PROTECTED]> writes:
> Remember, /etc/X11/window-managers is *only* used if the person using
> startx or logging in with XDM has no ~/.xsession file, which I image most
> experienced X users have.
Will there be a way for a user to change his wm without copying over
the whole .xssession? Maybe a .window-manager? I think that would be
useful, since there are many people who insist on a particular window
manager, but don't want to change anything else.
Falk Hueffner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package: ras, qvwm, descent
Hello, I intend to apply as a maintainer (as soon as I find somebody to scan my passport ;) and package: - ras (http://dspace.dial.pipex.com/nc/) Ras is a small utility that adds m extra files to a set of n files, such that the contents of the n original files can be regenerated from any n of the n+m original files and extra files. It is useful for transporting large files with floppies. It is released under the GPL and would go to slink/main/utils. The package is fairly easy and nearly finished. - qvwm (http://www-masuda.is.s.u-tokyo.ac.jp/~kourai/qvwm/qvwm-e.html) Qvwm is a window manager with look and feel similar to Windows 95, but with the common functions known from fvwm2 like a pager, SmartPlacement, EdgeResistance etc. It's license is not quite clear and that would have do be resolved before the package could be included in Debian. I have contacted the author about that. Packaging will be a bit more tricky, since I need to find a solution for the menu-method. - Descent (http://www.muppetlabs.com/linux/descent/, http://wouters.www.cistron.nl/ggi/ggi-descent.html) Descent is a commercial 3D game, to which the source has been released. You still need datafiles from the original game, though; the situation is similar to quake. There are currently two ports for Linux, one of them for ggi and one with multiple display targets; I will wait for the libggi package, I think, since that is a cleaner solution IMHO. It would go to slink/non-free/games. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bzip2 X
Michael Alan Dorman <[EMAIL PROTECTED]> writes: > Bdale Garbee <[EMAIL PROTECTED]> writes: > > As maintainer of gzip for Debian, I do not agree that having gzip > > fork a bzip2 when it sees a bzip2 magic number is a good idea. If > > we want to support multiple compression engines, I believe this > > should be handled in dpkg-source. > > I agree entirely. If one wants to do a 'file x', and chose gzip or > bzip2 based on those results, fine, but gzip shouldn't be expected to > have knowledge of some arbitrary set of formats. I cannnot quite understand that. gunzip already supports five or six different formats, so why not add another one? gunzip *is* designed to support multiple compression engines. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deb + tar + bzip2 suggestion
Joel Klecker <[EMAIL PROTECTED]> writes: > At 14:16 +0200 1998-04-18, Brederlow wrote: > >I think it would be a good idea to teach tar to unpack bzip2 files via > >the -z option, just as if it would be gzip. Alternativly one could > >teach gzip to use bzip2 for .bz2 archives or teach dpkg to distinguish > >between the two. > > Debian tar has a patch which hands off files to bzip2 if the -I option is > passed to it. Why wasn't the -z option expanded to recognize the bzip2 signature? That would seem to be a better solution to me. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [?] egcs increases C++ binary size dramatically
On Wed, 8 Apr 1998 01:01:46 +0200, Marcus Brinkmann <[EMAIL PROTECTED]> wrote: >> It's related to the fact that egcs does exception handling - add >> -fno-exceptions to your CFLAGS, and you'll get a shorter binary. > >I think this is not the right way to think of C++ programming. If you don't >use exceptions, you are free to disable them, but they are really an >integrated feature in the standard. GNU g++ had poorly to none exception >handling, egcs does a better job here, but maybe it is not optimized for >size yet. It seems that programs are larger even if they do not use exceptions at all (possibly even C programs). For those, it seems totally resonable to disable exceptions. It should probably even added to the policy, since it saves space. Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: source packaging format (was Re: Questions about plans for Emacs 20...)
On Sun, 5 Apr 1998 22:43:28 +0100, Enrique Zanardi <[EMAIL PROTECTED]> wrote: >Well, it's not broken, but we have no way to use pristine sources with >multiple-tar packages, so it may be improved (and it should). And there are *still* no source dependencies yet... Are there any plans about this in 2.x versions? Falk Hueffner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
