Re: /sys/boot, egcs vs. gcc, -Os
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: alas, that's progression for ye? 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. Has there been an `official' consensus reached about this from core or commiters? I am only speaking for John Polstra, a compiler guy, here. I agree. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 be coded in the makefile, while additions
can be passed to make.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 behind after a pkg_delete then it is broken and must be fixed. b. Shared library numbers should be bumped when the interface changes. I've made a number of mistakes with this on the GNOME ports, I'll admit. 2. FreeBSD Ports infrastructure problems. a. Depending on binaries without being able to get a version number. b. Not being able to upgrade a port in place. Jacques pointed to one solution to this: using one directory in /var/db/pkg per port. 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 that they often manage three releases in a 48 hour period. b. The GNOME ports must be seen as a unity. In fact I'm currently considering installing tests to stop the base packages being built from anything other than x11/gnome. The general rule for these packages is to pkg_delete gnomelibs-x.x.x and *everything* which depends on it, and then build x11/gnome. I'm going to add messages to the ports which announce this at uninstall time. I've been thinking a lot about this and other porting problems presented by GNOME and am trying to come up with solutions. At the moment I'm more concerned with actually getting the ports compiled right. But some thoughts: 1. Use -soname for binaries. Add this to $LDFLAGS or something, to get a version number installed into a binary then create extra magic or a script to test this in the DEPENDS. I don't know if this is possible, but there must be some field available which can be got with either file(1) or objdump(1). Same idea for scripts. 2. Add a version history in files. Each time a port is upgraded, add the new PKGNAME to files/history. Recreate these from the CVS history using a very clever script. Then use this to deinstall all old versions, or for upgrading. Upgrading requires much more dynamic PLISTs. Maybe a port should check for all files in PLIST before installing and refuse to install unless they are cleaned out first. 3. Change the DEPENDS mechanism in ports to use a Makefile.depends in each subdir. The port's makefile includes this, which in term includes all those from the ports it requires. Each port can then setup the environment for ports which depend on it, and check if it is correctly installed (using the appropriate magic in bsd.port.mk). There are a lot of other things need in a perfect ports/package system... Regards, -Jeremy -- | I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand |Never gonna be as big as Jesus, never gonna build a promised land |But that's, that's all right, OK with me... -Audio Adrenaline To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 if the rvalue is not in the lvalue? What about if the rvalue is added later?). You say creeping features, I say something that would have made sense since the beginning. The semantics would be yes and yes, respectively Bruce Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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:= ${CC:S/-Os//}
This is hard because it has to be coded in the makefile, while additions
can be passed to make.
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.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
http://www.freebsd.org _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 if the rvalue is added later?). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)
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 my example of a useful drop-in replacement of shared libXaw.so with libXaw3d.so, saying: az: Besides, most of the functionality that libXaw3d az: provides over libXaw is provided by Gtk+ themes. This lead me to conclude, you are aware of some other drop-in replacement for libXaw. But in any case, the drop-in replacement is one of the promises shared libraries pledge to deliver and do indeed deliver quite often. Using smth like -soname _may_ break this, if the run-time linker will refuse to use a different version of a library even if I want it to. Drop in replacements are perhaps a promise to you, but hardly a guarantee. I resent the personal reference here. The reason shared lib numbers were bumped up (or this was proposed anyways) was because of source and binary incompatable changes being made. Leaving the version number the same would introduce problems. I have no objections whatsoever to changes to shared lib numbers. I oppose to storing the information _in the binary_ and _relying on it_. The initial post I responded to, did not suggest such reliance outside of resolving interports' dependencies, but I'm afraid we may end up using it in the run-time linker. Nothing's stopping you from creating a replacement for an older version of Gtk+ or symlinking a specific version of Gtk+ to another library. Nothing currently does, indeed. Besides why whine hopelessly about something I'm sure you're never going to do? Think about all the other things that shared libs provide, like a reduction in disk and memory usage. As I mentioned, I'm using libXaw3d instead of libXaw on all of my machines. I also like NOT having to rebuild my little programs when I install new TCL libraries. I'm glad I do not have to recompile tcsh (and lots of other things) when I upgrade FreeBSD. Reduction in disk and memory usage is indeed _another_ promise shared libraries deliver... But it is NOT the one I was talking about. Exhale once in a while. It helps. Yeah, right, will you shave your back then? I asked you privately to change your tone and attitude, and to apologise. You refused. This would be my last response to you on this subject (probably on other subjects too). -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
-soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)
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 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 with different filenames for different libs? Do you think that the Gnome libs are going to stand still long enough for someone (you) to write a drop in replacement? See the the underlined part for reflection of my view on dealing with SOME software (Gnome). Besides, most of the functionality that libXaw3d provides over libXaw is provided by Gtk+ themes. 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... But in any case, the drop-in replacement is one of the promises shared libraries pledge to deliver and do indeed deliver quite often. Using smth like -soname _may_ break this, if the run-time linker will refuse to use a different version of a library even if I want it to. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 that they often manage three releases in a 48 hour period. [...] 1. Use -soname for binaries. Add this to $LDFLAGS or something, to get a version number installed into a binary then create extra magic or a script to test this in the DEPENDS. I don't know if this is possible, but there must be some field available which can be got with either file(1) or objdump(1). Same idea for scripts. 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 with different filenames for different libs? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -soname and shared libs (was Re: /sys/boot, egcs vs. gcc, -Os)
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 case, the drop-in replacement is one of the promises shared libraries pledge to deliver and do indeed deliver quite often. Using smth like -soname _may_ break this, if the run-time linker will refuse to use a different version of a library even if I want it to. Drop in replacements are perhaps a promise to you, but hardly a guarantee. The reason shared lib numbers were bumped up (or this was proposed anyways) was because of source and binary incompatable changes being made. Leaving the version number the same would introduce problems. Nothing's stopping you from creating a replacement for an older version of Gtk+ or symlinking a specific version of Gtk+ to another library. Besides why whine hopelessly about something I'm sure you're never going to do? Think about all the other things that shared libs provide, like a reduction in disk and memory usage. Exhale once in a while. It helps. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 with different filenames for different libs? Do you think that the Gnome libs are going to stand still long enough for someone (you) to write a drop in replacement? Besides, most of the functionality that libXaw3d provides over libXaw is provided by Gtk+ themes. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 the message
Re: /sys/boot, egcs vs. gcc, -Os
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_ too much to require those to be identical. The main issue with supporting both gcc and egcs -- at least beyond the next few weeks -- is really that they have different optimization characteristics. Space is sufficiently tight in boot2 that it's often been necessary to refer to the emitted code, and move C statements around, or do things like change ints to chars, just to get everything to fit. So supporting anything other than egcs is likely to become much more than a makefile problem. Also for reasons of space, internal boot2 functions in assembly language require use of a non-standard calling convention (the called functions pop argument from the stack), so ability to use some arbitrary ISO compiler can't be guaranteed on principle, and is fairly unlikely in practice. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 (lazy) reason that they looked like they'd be too painful to upgrade. Bah, if the ports-tree can make building Gnome easy, it's hardly painful (and I know KDE is easy to build from tarballs). It just takes a bit of patience. 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 dependencies; there's one lib (I forget which) which installs under one name, but all of the dependencies on it are under another name. The stuff seems to change it's mind on whether it wants to install under /usr/local or /usr/X11R6, so finding stuff is pretty complicated, and very dependent on version, because the darn install dirs change, just to make things worse. 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. The gnome stuff is really neat, else I'd never even bother. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 compatible for long. I'm aware of at least three ABI breakagese since 2.4.x. This is one reason that OI/uib will no longer work on Linux systems :-(. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 OPT_SMALL and OPT_FAST in the *.mk files, I
suppose.
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.
BTW, boot2/Makefile uses CFLAGS= to override any previous definition
of CFLAGS. This may break `make world' by removing -nostdinc.
Why don't we have a -= operator in make(1)?
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
http://www.freebsd.org _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 the ports are poorly designed or whathaveyou, but I can't imagine what older ports the kde ports are so sensitive to. Then of course, I tend to install from the CVS tree into /usr/local/kde... The gnome stuff is really neat, else I'd never even bother. Yup. Nothing like a load of core dumps in your home directory to make one's day :) - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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. That's news to me. Perhaps the ports are poorly designed or whathaveyou, but I can't imagine what older ports the kde ports are so sensitive to. Here's the deal. The KDE and gnome ports both have many dependencies on other ports, mainly shared libraries. Some of those may in turn depend on still other ports. In any case, it's a complicated dependency graph with a lot of nodes. 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 of them, and then make install in the KDE or gnome port. Otherwise you end up with a hodge-podge of new ports and old dependencies, and they don't play together nicely. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 of them, and then make install in the KDE or gnome port. Otherwise you end up with a hodge-podge of new ports and old dependencies, and they don't play together nicely. 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. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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. 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 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 port. Oops, it requires a newer version of libjpeg. You have to remove the old libjpeg so that the newer one can be installed without a lot of complaints. Oops, a bunch of other ports used the old libjpeg. Now you have to upgrade those ports too. Oops, some of those ports depend on libXpm, and a new version of it is needed now. Oops, now some other ports that used the old libXpm need to be upgraded. At this point, you throw up your hands, pkg_delete -f everything, and reinstall all your ports from scratch. And the next time you're tempted to upgrade a port, you decide it would be easier to just buy a new machine. :-) John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 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 port. Oops, it requires a newer version of libjpeg. You have to remove the old libjpeg so that the newer one can be installed without a lot of complaints. Oops, a bunch of other ports used the old libjpeg. Now you have to upgrade those ports too. Oops, some of those ports depend on libXpm, and a new version of it is needed now. Oops, now some other ports that used the old libXpm need to be upgraded. At this point, you throw up your hands, pkg_delete -f everything, and reinstall all your ports from scratch. And the next time you're tempted to upgrade a port, you decide it would be easier to just buy a new machine. :-) John I agree completely. I had just recently run into this problem in a big way over gnome. I am not familiar at all with the inner workings of the 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 -- i.e. the leaves know which branch they are on but the branches don't know which leaves they bear. If this is in fact the case then it seems to me that a first step in improving the behaviour of the port/package system is to make the database be a leaf-to-branch and branch-to-leaf linked relationship tree that can be traversed as needed. I'm not sure of the standard Computer Science jargon to describe such a tree. Tom To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
port dependencies (was Re: /sys/boot, egcs vs. gcc, -Os)
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 port. Oops, it requires a newer version of libjpeg. You have to remove the old libjpeg so that the newer one can be installed without a lot of complaints. Oops, a bunch of other ports used the old libjpeg. Now you have to upgrade those ports too. Oops, some of those ports depend on libXpm, and a new version of it is needed now. Oops, now some other ports that used the old libXpm need to be upgraded. Now I understand what you are saying. The current ports structure only goes one way through the dependency graph. Maybe when building a particular port, not only should dependencies be checked, but anything that depends on the port needs to be rebuilt. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 packages in each Makefile. The `required-by' list is not stored - it would be a nightmare to maintain. 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 contains the `required-by' list and is maintained automatically by the package management tools (eg installing `foo' which depends on `bar' adds a line `foo' to /var/db/pkg/bar/+REQUIRED_BY, which is removed if the package in removed). The problem is that the package management system provides `add' and `delete' functions only, and the delete function (by default) requires all dependent packages to be deleted first. (You can force the delete to ignore the dependent packages, but that loses the +REQUIRED_BY file contents). 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: mv /var/db/pkg/bar-1.1/+REQUIRED_BY /var/db/pkg/save pkg_delete bar-1.1 pkg_add bar-1.2 mv /var/db/pkg/save /var/db/pkg/bar-1.2/+REQUIRED_BY This approach can't pick up the dependent packages that really do need to be re-compiled against the newly installed package. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: port dependencies (was Re: /sys/boot, egcs vs. gcc, -Os)
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. Now you decide to upgrade one of them, the foo port. Oops, it requires a newer version of libjpeg. You have to remove the old libjpeg so that the newer one can be installed without a lot of complaints. Oops, a bunch of other ports used the old libjpeg. Now you have to upgrade those ports too. Oops, some of those ports depend on libXpm, and a new version of it is needed now. Oops, now some other ports that used the old libXpm need to be upgraded. Now I understand what you are saying. The current ports structure only goes one way through the dependency graph. Maybe when building a particular port, not only should dependencies be checked, but anything that depends on the port needs to be rebuilt. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org Exactly correct. Tom To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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. 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 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 port. Oops, it requires a newer version of libjpeg. You have to remove the old libjpeg so that the newer one can be installed without a lot of complaints. Oops, a bunch of other ports used the old libjpeg. Now you have to upgrade those ports too. Oops, some of those ports depend on libXpm, and a new version of it is needed now. Oops, now some other ports that used the old libXpm need to be upgraded. 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 (and in both sets of directories, depending on the age of the older ports). Just to make everything totally confused, because some insane folks want to have multiple versions active concurrently, the name of those config files, which exist in multiple places, have multiple names. Each of the ports of the apps, which need all these libs, have configuration scripts that go looking for all these misnamed and misfiled config scripts, and those configuration scripts alway seem to find the oldest and most out-of-date config script possible. Bleah! At this point, you throw up your hands, pkg_delete -f everything, and reinstall all your ports from scratch. And the next time you're tempted to upgrade a port, you decide it would be easier to just buy a new machine. :-) John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 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 packages in each Makefile. The `required-by' list is not stored - it would be a nightmare to maintain. 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 contains the `required-by' list and is maintained automatically by the package management tools (eg installing `foo' which depends on `bar' adds a line `foo' to /var/db/pkg/bar/+REQUIRED_BY, which is removed if the package in removed). The problem is that the package management system provides `add' and `delete' functions only, and the delete function (by default) requires all dependent packages to be deleted first. (You can force the delete to ignore the dependent packages, but that loses the +REQUIRED_BY file contents). 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: mv /var/db/pkg/bar-1.1/+REQUIRED_BY /var/db/pkg/save pkg_delete bar-1.1 pkg_add bar-1.2 mv /var/db/pkg/save /var/db/pkg/bar-1.2/+REQUIRED_BY This approach can't pick up the dependent packages that really do need to be re-compiled against the newly installed package. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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, files that must be preserved (shared libraries mainly) over an update must be tagged. If libfoo-1.0 is installed and I upgrade to libfoo-2.3, the libfoo-1.0 package should be removed except /usr/local/share/libfoo.so.1.0. Then libfoo-2.3 gets installed and *inherits* /usr/local/share/libfoo.so.1.0 in its +CONTENTS so that if you want to do a wholesale removal of the libfoo package in the future, you can do it. A completely different approach to this dependency nightmare is to link statically. I know there are drawbacks to this and the costs are too great in numerous situations. But if you *can* practically do this, you can demote a runtime dependency to a build time dependency which is a Good Thing for your sanity. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 contains the `required-by' list and is maintained automatically by the package management tools (eg installing `foo' which depends on `bar' adds a line `foo' to /var/db/pkg/bar/+REQUIRED_BY, which is removed if the package in removed). I've never found the +REQUIRED_BY data to be consistently maintained for me - i.e. there are usually dependent packages referenced there which no longer exist on my system, several versions of packages when I've done a remove old/add new version, etc. I should spend some time to try and figure out what's causing this inconsistency..does anyone else see behaviour like this? Kris - The Feynman problem-solving algorithm: 1. Write down the problem 2. Think real hard 3. Write down the solution To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 can use something like: For an update to work, files that must be preserved (shared libraries mainly) over an update must be tagged. If libfoo-1.0 is installed and I upgrade to libfoo-2.3, the libfoo-1.0 package should be removed except /usr/local/share/libfoo.so.1.0. Then libfoo-2.3 gets installed and *inherits* /usr/local/share/libfoo.so.1.0 in its +CONTENTS so that if you want to do a wholesale removal of the libfoo package in the future, you can do it. A completely different approach to this dependency nightmare is to link statically. I know there are drawbacks to this and the costs are too great in numerous situations. But if you *can* practically do this, you can demote a runtime dependency to a build time dependency which is a Good Thing for your sanity. 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 cut and dried as the libs, because the libs follow usually one set of rules (laid down by the runtime linker) but the config files, every port seems to use it's own set of rules. And there is no static linking for config files, to save you. A lot of these config files only take effect while building other libs or applications, which means they sometimes won't affect regular runtime problems, just beating the heck out of the upgrade nightmare. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 XFree86-3.3.3.1). If libfoo-1.0 is installed and I upgrade to libfoo-2.3, the libfoo-1.0 package should be removed except /usr/local/share/libfoo.so.1.0. Then libfoo-2.3 gets installed and *inherits* /usr/local/share/libfoo.so.1.0 in its +CONTENTS so that if you want to do a wholesale removal of the libfoo package in the future, you can do it. The problem with this approach is that you lose the fact that xbar depends on libfoo-1.0, whilst xyzzy depends on libfoo-2.3. This makes updating libfoo-2.3 to libfoo-3.1 messy - especially if xbar has been deleted in the interim (meaning libfoo.so.1.0 is no longer needed). I'd prefer to see the upgrade delete the unnecessary bits of libfoo-1.0, but leave the db/pkg entry in place - with a cut-down +CONTENTS. This makes it easier to get rid of the remaining bits when any dependencies are deleted. (For extra marks, add a flag so that libfoo-1.0 is deleted automatically when the last dependency is removed). (Of course, as Chuck Robey points out, this becomes much harder when config files are taken into account). Kris Kennaway kkenn...@physics.adelaide.edu.au wrote: I've never found the +REQUIRED_BY data to be consistently maintained for me - I've seen the same, but I've never bothered digging into the problem. Feel free to look into the problem. It might be worthwhile asking Jordan if he is aware of the problem and/or has any ideas. 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 configuration (xf86site.def) changes depending on whether or not tk exists). Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 (and in both sets of directories, depending on the age of the older ports). Yes, I do find that very annoying. I'd like to see everything (including X) use one prefix. The next time that I install a system from scratch, I'll have everything under /opt (I use /usr/X11R6 and /opt right now) to see how it goes. I can't recall why we have /usr/X11R6, other than because of assumptions in lotsa X packages. Just to make everything totally confused, because some insane folks want to have multiple versions active concurrently, the name of those config files, which exist in multiple places, have multiple names. Insane? ``Though this be madness, yet there is a method in 't.'' If we were to remove all gtk ports but the latest (gtk12), as an example, then we would have to remove also approximately 34 ports that depend upon the older versions of GTK. Each of the ports of the apps, which need all these libs, have configuration scripts that go looking for all these misnamed and misfiled config scripts, and those configuration scripts alway seem to find the oldest and most out-of-date config script possible. AFAIK, all of the ports that depend upon gtk (again for example), correctly search for the version-dependant configuration script name (i.e. gtk10-config, gtk12-config ...). If there are those that do not, please send-pr them. If you have a better suggestion for handling this necessary complexity, I'd like to hear it. Upgrading the ports is hard enough without tilting at windmills. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 cut and dried as the libs, because the libs follow usually one set of rules (laid down by the runtime linker) but the config files, every port seems to use it's own set of rules. And there is no static linking for config files, to save you. A lot of these config files only take effect while building other libs or applications, which means they sometimes won't affect regular runtime problems, just beating the heck out of the upgrade nightmare. Maybe I'm misunderstanding ... are we talking about scripts such as gnome-config or gtk12-config? These seem to be a blessing to me. It would be an order of magnitude harder to maintain GTK using ports if it weren't for the simplicity of passing GTK_CONFIG=gtk12-config (or whichever applies) to the configure script. What problems do you believe these are causing for upgrades? Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 is gtk-1.2.1. I think this contributes to the upgrade problem and tracking dependencies with the information in /var/db/pkg. I just reread that and seem to be having trouble making myself clear right now. If that didn't make perfect sense, I'll try again tomorrow after some sleep. ;-) Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 configuration (xf86site.def) changes depending on whether or not tk exists). And if the tcl/tk stuff updated as often as the gtk/glib/gnome/kde stuff does, you'd be hearing the blues about that too. Some folks here remember my vociferous opposition to the tcl multiple version support, but once I lost the battle, it would have been poor grace to keep on fighting that. I know Satoshi won't forget that. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ports dependencies (Re: /sys/boot, egcs vs. gcc, -Os)
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 bits a little so we can have a meaningful discussion? :) About the shlib stuff: the biggest problem is not the lack of support by the ports system, but the incompatibilities between various libfoo.so.Ns floating around. The shlib versions are almost never bumped correctly, and that results in the why doesn't my libintl.so.1 work with the latest gnome when it's building on Satoshi's machine problems. To (at least partially) solve this problem, I added a ALWAYS_BUILD_DEPENDS variable to the latest bsd.port.mk. Please recommend people to try it if they are having these kinds of stuff. * From: Jacques Vidrine n...@nectar.com * 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 is gtk-1.2.1. I * think this contributes to the upgrade problem and tracking * dependencies with the information in /var/db/pkg. Finally! I've been talking about this for years, the only part that was missing was a programmer. Now, do I hear a volunteer? :) -PW P.S. The past few volunteers have disappeared without trace but I have a feeling Jacques is different. : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 dependencies; there's one lib (I forget which) which installs under one name, but all of the dependencies on it are under another name. The stuff seems to change it's mind on whether it wants to install under /usr/local or /usr/X11R6, so finding stuff is pretty complicated, and very dependent on version, because the darn install dirs change, just to make things worse. I'll bet the library you're thinking of is libtix. David O'Brien just committed fixes for it yesterday. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 is produce a smaller code. Egcs needs it, gcc doesn't. 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 can be still compiled with gcc. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 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. 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 can be still compiled with gcc. Why? The compiler in -current is egcs, not gcc. If you want to use the old compiler, then use the old sources for boot too. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 kernel[1024]. Please fix so it can be still compiled with gcc. 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? Has there been an `official' consensus reached about this from core or commiters? --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 can be still compiled with gcc. I didn't see any changes to loader/boot[012] lately. EGCS requires -Os, but gcc should be able to compile it within limits, just like in -stable. Are you sure you didn't test with egcs after removing -Os? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 compiled with gcc. I didn't see any changes to loader/boot[012] lately. EGCS requires -Os, but gcc should be able to compile it within limits, just like in -stable. Are you sure you didn't test with egcs after removing -Os? 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 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -c /usr/src/sys/boot/i386/boot2/boot2.c -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 fix so it can be still compiled with gcc. I didn't see any changes to loader/boot[012] lately. EGCS requires -Os, but gcc should be able to compile it within limits, just like in -stable. Are you sure you didn't test with egcs after removing -Os? 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 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -c /usr/src/sys/boot/i386/boot2/boot2.c Revision 1.12 of the Makefile contains option changes for egcs. If you want to use gcc, use rev 1.11 of the Makefile. (Jeez, guys!) -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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. 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. Has there been an `official' consensus reached about this from core or commiters? I am only speaking for John Polstra, a compiler guy, here. -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -c /usr/src/sys/boot/i386/boot2/boot2.c You removed the -Os but you didn't add back the -O2 that originally was there. -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
* 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 speaking for John Polstra, a compiler guy, here. Speaking for Satoshi Asami, the ports guy, I agree with John. I for one will hate to see the ports people having to worry about 4.0-gcc (they already have 4.0-egcs and 3.1-gcc to worry about...). -PW To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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+++ Y To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 for ye? 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. Has there been an `official' consensus reached about this from core or commiters? I am only speaking for John Polstra, a compiler guy, here. John, no complaint (I figure some recompiling is the cost of running current) but could you please repost here some stuff that I think you said once already? I'm sorry, but I have an error, and I want to make sure it's recompile time. Here's the last part of the dump: 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 /usr/local/lib -rpath /usr/X11R6/lib 15 /usr/libexec/elf/ld: warning: libstdc++.so.2, needed by /usr/local/lib/libkdecore.so, may conflict with libstdc++.so.3 /usr/lib/libstdc++.so.2: undefined reference to `__unwind_function' /usr/lib/libstdc++.so.2: undefined reference to `__find_first_exception_table_match' /usr/local/lib/libkdecore.so: undefined reference to `_vt$11QPushButton$12QPaint Device' /usr/lib/libstdc++.so.2: undefined reference to `__register_exceptions' /usr/local/lib/libkdecore.so: undefined reference to `_vt$11QPushButton' I thought you had patched ld-elf.so.1 so this (__register_exceptions) wouldn't get hit again, but maybe I'm wrong, could you please bang me on the head with the story, and THIS TIME I'll try to remember it? +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 /usr/local/lib -rpath /usr/X11R6/lib 15 /usr/libexec/elf/ld: warning: libstdc++.so.2, needed by /usr/local/lib/libkdecore.so, may conflict with libstdc++.so.3 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 upon. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 conftest.C -lkdecore -lqt -lXext -lX11 -rpath /usr/local/lib -rpath /usr/X11R6/lib 15 /usr/libexec/elf/ld: warning: libstdc++.so.2, needed by /usr/local/lib/libkdecore.so, may conflict with libstdc++.so.3 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 upon. Thanks for the clue, John! As much as I hate redoing the KDE and gnome ports, it looks like doing that again ... John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 painful to upgrade. 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 having to rebuild the mess, would you want to pack up some packages from me? They'll be strictly current-based, and I won't bother you until a collection is complete (if you have interest .. some are interesting). Understand I'll probably take at least 10 days to do this. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
* 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 4.0. -PW To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 compiler, then use the old sources for boot too. Everything should be buildable with CC=aac (any ANSI compiler), but that's asking too much for programs like kernels and boot blocks. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 be identical. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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.
Actually, they don't. Compiler-specific options can be put in ${CC}.
Perhaps they even should be.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 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
suppose.
John
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 upon. Thanks for the clue, John! As much as I hate redoing the KDE and gnome ports, it looks like doing that again ... 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. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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 painful to upgrade. Bah, if the ports-tree can make building Gnome easy, it's hardly painful (and I know KDE is easy to build from tarballs). It just takes a bit of patience. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /sys/boot, egcs vs. gcc, -Os
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
suppose.
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.
BTW, boot2/Makefile uses CFLAGS= to override any previous definition
of CFLAGS. This may break `make world' by removing -nostdinc.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
