Re: /sys/boot, egcs vs. gcc, -Os

1999-04-12 Thread Poul-Henning Kamp
In message 199904080049.raa76...@vashon.polstra.com, John Polstra writes: In article xfmail.990407210734.asmo...@wxs.nl, Jeroen Ruigrok/Asmodai asmo...@wxs.nl wrote: This raises an interesting point I think. Do we need to maintain gcc/egcs compatibility? Or do we, since we track CURRENT, say:

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Bruce Evans
CC+=-Os in individual Makefiles works about as well as CFLAGS+=-Os for adding flags. That's not very well. Removing unwanted additions is hard. Why don't we have a -= operator in make(1)? Substitution can replace -= in may cases, e.g.: CC:=${CC:S/-Os//} This is hard because it has to

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Jeremy Lea
Hi, On Thu, Apr 08, 1999 at 12:31:24PM -0400, Chuck Robey wrote: [much whining snipped :)] Your confusing a bunch of different issues here: 1. Poor porting. a. Ports should not leave behind old files, other than site configuration files (like samba.conf). If a port leaves any files

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Brian Feldman
On Sat, 10 Apr 1999, Bruce Evans wrote: But what's wrong with having a specific -= operator? It would make code more readable, which is a plus. It would be obvious for people to look for such before resorting to substition rules. Creeping featurism. Obscure semantics (would it do nothing

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Brian Feldman
On Fri, 9 Apr 1999, Bruce Evans wrote: CC+=-Os in individual Makefiles works about as well as CFLAGS+=-Os for adding flags. That's not very well. Removing unwanted additions is hard. Why don't we have a -= operator in make(1)? Substitution can replace -= in may cases, e.g.: CC:=

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Bruce Evans
But what's wrong with having a specific -= operator? It would make code more readable, which is a plus. It would be obvious for people to look for such before resorting to substition rules. Creeping featurism. Obscure semantics (would it do nothing if the rvalue is not in the lvalue? What about

Re: -soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-09 Thread Mikhail Teterin
Alex Zepeda once wrote: This is a good knews. Does this mean, I can drop-in some GTk library and make libXaw.so a symlink to it? This would only support my point... That's like trying to replace libz with libc. Did you notice what I said about the themes? I noticed, that you discarded

-soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-09 Thread Mikhail Teterin
Alex Zepeda once wrote: I'd like to voice my opposition to this. While it maybe an ^ acceptable way to work around poor (or non-existant) release engineering of SOME

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Mikhail Teterin
Jeremy Lea once wrote: 3. GNOME problems. a. GNOME has no release engineering. The libraries break APIs for every pico number bump just about. Or they fix bugs and remove workarounds at higher levels. Also ESR's $%^*@ advice of release early and release often means

Re: -soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-09 Thread Alex Zepeda
On Fri, 9 Apr 1999, Mikhail Teterin wrote: This is a good knews. Does this mean, I can drop-in some GTk library and make libXaw.so a symlink to it? This would only support my point... That's like trying to replace libz with libc. Did you notice what I said about the themes? But in any

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-09 Thread Alex Zepeda
I'd like to voice my opposition to this. While it maybe an acceptable way to work around poor (or non-existant) release engineering of SOME software, making this a rule may defeat one of the major purposes of shared libraries: drop-in replacement. Think of libXaw3d, for example. What's wrong

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Jordan K. Hubbard
Actually, they don't. Compiler-specific options can be put in ${CC}. I'm leading him... leading... *BLAM!* *BLAM!* Yes! Got him with both barrels, and he was really moving too! :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Robert Nordier
John Polstra wrote: Bruce Evans wrote: Everything should be buildable with CC=aac (any ANSI compiler), but that's asking too much for programs like kernels and boot blocks. The problem in this case is just that the compilers require different command line options. It's asking _way_

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Chuck Robey
On Wed, 7 Apr 1999, Alex Zepeda wrote: On Wed, 7 Apr 1999, John Polstra wrote: Chuck Robey wrote: Thanks for the clue, John! As much as I hate redoing the KDE and gnome ports, it looks like doing that again ... I don't blame you. I've never even built them, for the simple

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Warner Losh
In message pine.bsf.4.05.9904072108290.94006-100...@zippy.dyn.ml.org Alex Zepeda writes: : That was one of the BIG pitfalls of egcs, binary incompatable C++ programs : and libs. Sounds like you're overdue for your favorite shot of caffiene. g++ and its derivitives have never been binary

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Brian Feldman
On Thu, 8 Apr 1999, Bruce Evans wrote: Actually, they don't. Compiler-specific options can be put in ${CC}. Perhaps they even should be. But in this case, we want -Os (egcs) or -O2 (gcc) only for building boot -- not for everything. It could be parameterized with make macros like

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Alex Zepeda
On Thu, 8 Apr 1999, Chuck Robey wrote: When Satoshi builds stuff, it's in a real clean environment, but in fact, all the gnome and kde ports are extraordinarly sensitive to stuff from older ports hanging around. That's why folks are wary of upgrading those guys. That's news to me. Perhaps

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread John Polstra
Alex Zepeda wrote: On Thu, 8 Apr 1999, Chuck Robey wrote: When Satoshi builds stuff, it's in a real clean environment, but in fact, all the gnome and kde ports are extraordinarly sensitive to stuff from older ports hanging around. That's why folks are wary of upgrading those guys.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Jacques Vidrine
On 8 April 1999 at 11:49, John Polstra j...@polstra.com wrote: [snip] Everything works fine for the initial installation. But now 3 months later you want to upgrade to the new version. About the only reliable way to do that is to manually track down all the dependencies, pkg_delete every one

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread John Polstra
Jacques Vidrine wrote: Maintainers of these ports would appreciate PRs if the dependencies are broken. The ports infrastructure has the mechanisms necessary to handle these dependencies, but the port maintainer may not catch every dependency. I am not saying the dependencies are broken.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Tom Bartol
On Thu, 8 Apr 1999, John Polstra wrote: I am not saying the dependencies are broken. I'm just lamenting the general problem that it's difficult to upgrade a port that depends on a lot of things. It's a general structural problem, and I don't know how to fix it. Say you've got a bunch

port dependencies (was Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-08 Thread Jacques Vidrine
On 8 April 1999 at 12:24, John Polstra j...@polstra.com wrote: [snip] Say you've got a bunch of ports that all depend on the same shared library -- maybe libjpeg or libXpm. You've had them installed for a few months, and they all work fine. Now you decide to upgrade one of them, the foo

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Peter Jeremy
Tom Bartol bar...@salk.edu wrote: ports/package database system but it occurred to me that perhaps the database is currently only storing which packages a given package depends upon and is NOT storing which packages depend upon a given package The port source tree stores a list of pre-requisite

Re: port dependencies (was Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-08 Thread Tom Bartol
On Thu, 8 Apr 1999, Jacques Vidrine wrote: On 8 April 1999 at 12:24, John Polstra j...@polstra.com wrote: [snip] Say you've got a bunch of ports that all depend on the same shared library -- maybe libjpeg or libXpm. You've had them installed for a few months, and they all work fine.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Chuck Robey
On Thu, 8 Apr 1999, John Polstra wrote: Jacques Vidrine wrote: Maintainers of these ports would appreciate PRs if the dependencies are broken. The ports infrastructure has the mechanisms necessary to handle these dependencies, but the port maintainer may not catch every dependency.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Chas Pinckard
Suggestion: How bout a version detection flag for the update pkgs and a version requirement to the newly built ports? C~P Peter Jeremy wrote: Tom Bartol bar...@salk.edu wrote: ports/package database system but it occurred to me that perhaps the database is currently only storing which

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread John Fieber
On Fri, 9 Apr 1999, Peter Jeremy wrote: There's no mechanism for updating a package - and it's not clear (to me anyway) how this can be done safely in a general way. Where the update is only minor (and won't affect the dependent packages), you can use something like: For an update to work,

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Kris Kennaway
On Fri, 9 Apr 1999, Peter Jeremy wrote: On installation, the packages database stores both dependency directions. /var/db/pkg/PACKAGE/+CONTENTS contains the list of pre-requisite packages in `...@pkgdep' records. The +CONTENTS file is part of the package. /var/db/pkg/PACKAGE/+REQUIRED_BY

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Chuck Robey
On Thu, 8 Apr 1999, John Fieber wrote: On Fri, 9 Apr 1999, Peter Jeremy wrote: There's no mechanism for updating a package - and it's not clear (to me anyway) how this can be done safely in a general way. Where the update is only minor (and won't affect the dependent packages), you

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Peter Jeremy
John Fieber jfie...@indiana.edu wrote: For an update to work, files that must be preserved (shared libraries mainly) over an update must be tagged. This is why I said my approach only worked for `minor' updates - which means those that don't bump library versions etc (eg XFree86-3.3.3 to

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Jacques Vidrine
On 8 April 1999 at 19:25, Chuck Robey chu...@mat.net wrote: [snip] And on top of that, there are about 5 top tracks of libs, each of these 5 tracks (that have lots depending on them) has lived in both /usr/local and in /usr/X11R6 in recent times, both leave ascii configuration files behind

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Jacques Vidrine
On 8 April 1999 at 19:57, Chuck Robey chu...@mat.net wrote: Don't forget, with all the gnome and gtk ports (and the kde things) there are various files with config in their names, that a bunch of other ports depend on ... just to add confusion, and the rules for these dependencies aren't as

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Jacques Vidrine
I get the feeling (not for the first time) that perhaps it is a mistake to have the package database indexed by PKGNAME. Or at least, it seems that there isn't an easy way to get from what I'll refer to as the ``port name'' from PKGNAME. For example, the port gtk12 was once gtk-1.2.0. Now it

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Chuck Robey
On Fri, 9 Apr 1999, Peter Jeremy wrote: Chuck Robey chu...@mat.net wrote: Don't forget, with all the gnome and gtk ports (and the kde things) tcl and tk also install various version-specific information (and has anyone else noticed that tk depends on X11 (ie XFree86) and the XFree86

ports dependencies (Re: /sys/boot, egcs vs. gcc, -Os)

1999-04-08 Thread Satoshi - the Ports Wraith - Asami
I'm just skimming through this discussion, as I don't have time to read them all. People, I know you are annoyed by many stupid things software authors have done in the past to make your life miserable (and believe me, I probably have more horror stories than most of you), but can you trim those

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-08 Thread Bruce Albrecht
Chuck Robey writes: If that were true, but it's not. Older versions of the config files and libraries can very easily cause the ports to fail to build. Every time I upgrade stuff, I have to go about doing search and destroy on old stuff. On top of that, there are various mistakes in

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Daniel C. Sobral
Andrey A. Chernov wrote: Now /sys/boot can't be compiled with gcc due to non-existent -Os added. Is it intentional or can be removed for backward compatibility? It can be removed for backward compatibility. What it does is produce a smaller code. Egcs needs it, gcc doesn't. -- Daniel C.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Andrey A. Chernov
On Thu, Apr 08, 1999 at 01:15:32AM +0900, Daniel C. Sobral wrote: Andrey A. Chernov wrote: Now /sys/boot can't be compiled with gcc due to non-existent -Os added. Is it intentional or can be removed for backward compatibility? It can be removed for backward compatibility. What it does

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
In article 19990407221941.a91...@nagual.pp.ru, Andrey A. Chernov a...@nagual.pp.ru wrote: On Thu, Apr 08, 1999 at 01:15:32AM +0900, Daniel C. Sobral wrote: Andrey A. Chernov wrote: Now /sys/boot can't be compiled with gcc due to non-existent -Os added. Is it intentional or can be

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Jeroen Ruigrok/Asmodai
On 07-Apr-99 Andrey A. Chernov wrote: The problem is deeper. When I reemove it, I got this error: -2100 bytes available tried with -O2 yet? it seems that boot2 needs to be reduced, and I don't know why it becomes that big and what can be reduced. First candidates are static cmd[512] and

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Daniel C. Sobral
Andrey A. Chernov wrote: The problem is deeper. When I reemove it, I got this error: -2100 bytes available it seems that boot2 needs to be reduced, and I don't know why it becomes that big and what can be reduced. First candidates are static cmd[512] and kernel[1024]. Please fix so it

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Andrey A. Chernov
On Thu, Apr 08, 1999 at 08:09:43AM +0900, Daniel C. Sobral wrote: -2100 bytes available it seems that boot2 needs to be reduced, and I don't know why it becomes that big and what can be reduced. First candidates are static cmd[512] and kernel[1024]. Please fix so it can be still

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Robert Nordier
Andrey A. Chernov wrote: On Thu, Apr 08, 1999 at 08:09:43AM +0900, Daniel C. Sobral wrote: -2100 bytes available it seems that boot2 needs to be reduced, and I don't know why it becomes that big and what can be reduced. First candidates are static cmd[512] and kernel[1024]. Please

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
In article xfmail.990407210734.asmo...@wxs.nl, Jeroen Ruigrok/Asmodai asmo...@wxs.nl wrote: This raises an interesting point I think. Do we need to maintain gcc/egcs compatibility? Or do we, since we track CURRENT, say: alas, that's progression for ye? Yep, alas, that's progression for ye.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
In article 19990408040432.a74...@nagual.pp.ru, Andrey A. Chernov a...@nagual.pp.ru wrote: Yes, of course I am shure. BTW, I see lots of malign options in cc call, maybe they play role. cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -fno-builtin -malign-functions=0 -malign-jumps=0

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Satoshi - the Wraith - Asami
* From: John Polstra j...@polstra.com * Yep, alas, that's progression for ye. We have never supported mix * match of sourceballs from different releases. We do our best * to support running old executables on newer systems, but that's a * completely different issue. : * I am only

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Andrey A. Chernov
On Wed, Apr 07, 1999 at 05:50:24PM -0700, John Polstra wrote: You removed the -Os but you didn't add back the -O2 that originally was there. Thanx, it works now. It was the reason I overlook. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Chuck Robey
On Wed, 7 Apr 1999, John Polstra wrote: In article xfmail.990407210734.asmo...@wxs.nl, Jeroen Ruigrok/Asmodai asmo...@wxs.nl wrote: This raises an interesting point I think. Do we need to maintain gcc/egcs compatibility? Or do we, since we track CURRENT, say: alas, that's progression

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
Chuck Robey wrote: configure:4096: /bin/sh ./libtool --silent --mode=link c++ -o conftest -Os -pipe -I/usr/local/include -I/usr/X11R6/include/X11/qt -I/usr/X11R6/include -I/usr/l ocal/include/giflib -s -L/usr/local/lib -L/usr/X11R6/lib conftest.C -lkdecore -lqt -lXext -lX11 -rpath

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Chuck Robey
On Wed, 7 Apr 1999, John Polstra wrote: Chuck Robey wrote: configure:4096: /bin/sh ./libtool --silent --mode=link c++ -o conftest -Os -pipe -I/usr/local/include -I/usr/X11R6/include/X11/qt -I/usr/X11R6/include -I/usr/l ocal/include/giflib -s -L/usr/local/lib -L/usr/X11R6/lib

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
Chuck Robey wrote: Thanks for the clue, John! As much as I hate redoing the KDE and gnome ports, it looks like doing that again ... I don't blame you. I've never even built them, for the simple (lazy) reason that they looked like they'd be too painful to upgrade. John --- John Polstra

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Chuck Robey
On Wed, 7 Apr 1999, John Polstra wrote: Chuck Robey wrote: Thanks for the clue, John! As much as I hate redoing the KDE and gnome ports, it looks like doing that again ... I don't blame you. I've never even built them, for the simple (lazy) reason that they looked like they'd be too

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Satoshi - the Wraith - Asami
* From: Chuck Robey chu...@mat.net * I'm very close to relying on packages for them. I'll have to see if * there are *very* up-to-date packages. If there aren't, and I end up As long as they build, FTP packages are usually within one week (usually less) of the ports tree on both 3.1 and

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Bruce Evans
it seems that boot2 needs to be reduced, and I don't know why it becomes that big and what can be reduced. First candidates are static cmd[512] and kernel[1024]. Please fix so it can be still compiled with gcc. Why? The compiler in -current is egcs, not gcc. If you want to use the old

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
Bruce Evans wrote: Everything should be buildable with CC=aac (any ANSI compiler), but that's asking too much for programs like kernels and boot blocks. The problem in this case is just that the compilers require different command line options. It's asking _way_ too much to require those to

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Bruce Evans
Everything should be buildable with CC=aac (any ANSI compiler), but that's asking too much for programs like kernels and boot blocks. The problem in this case is just that the compilers require different command line options. It's asking _way_ too much to require those to be identical.

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread John Polstra
Bruce Evans wrote: The problem in this case is just that the compilers require different command line options. It's asking _way_ too much to require those to be identical. Actually, they don't. Compiler-specific options can be put in ${CC}. Perhaps they even should be. But in this case, we

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Alex Zepeda
On Wed, 7 Apr 1999, Chuck Robey wrote: Bzzt. You've got something old that's still using libstdc++.so.2. You can't combine that with something that uses libstdc++.so.3. I.e., you can't use both versions at the same time. I'd suggest rebuilding the port and everything that it depends

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Alex Zepeda
On Wed, 7 Apr 1999, John Polstra wrote: Chuck Robey wrote: Thanks for the clue, John! As much as I hate redoing the KDE and gnome ports, it looks like doing that again ... I don't blame you. I've never even built them, for the simple (lazy) reason that they looked like they'd be too

Re: /sys/boot, egcs vs. gcc, -Os

1999-04-07 Thread Bruce Evans
Actually, they don't. Compiler-specific options can be put in ${CC}. Perhaps they even should be. But in this case, we want -Os (egcs) or -O2 (gcc) only for building boot -- not for everything. It could be parameterized with make macros like OPT_SMALL and OPT_FAST in the *.mk files, I