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:
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
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
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
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:=
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
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
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
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
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
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
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
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_
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
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
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
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
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.
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
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.
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
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
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
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.
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.
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
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,
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
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
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
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
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
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
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
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
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
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?
--
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
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.
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
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
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
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
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
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
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.
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
* 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
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+++
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
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
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
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
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
* 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
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
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
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.
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
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
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
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
61 matches
Mail list logo
