In message <199904080049.raa76...@vashon.polstra.com>, John Polstra writes:
>In article , Jeroen
>Ruigrok/Asmodai 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?"
>
>
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 c
> 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 wr
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 di
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
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 mea
>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 abo
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 no
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.
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
>> "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 i
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
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 b
On Fri, 9 Apr 1999, Peter Jeremy wrote:
> Chuck Robey 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
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 i
On 8 April 1999 at 19:57, Chuck Robey 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 dri
On 8 April 1999 at 19:25, Chuck Robey 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
John Fieber 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 l
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), y
On Fri, 9 Apr 1999, Peter Jeremy wrote:
> On installation, the packages database stores both dependency
> directions. /var/db/pkg//+CONTENTS contains the list of
> pre-requisite packages in `...@pkgdep' records. The +CONTENTS file is
> part of the package. /var/db/pkg//+REQUIRED_BY contains the
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 wor
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 wrote:
> >ports/package database system but it occurred to me that perhaps the
> >database is currently only storing which packages a given
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 dep
On Thu, 8 Apr 1999, Jacques Vidrine wrote:
> On 8 April 1999 at 12:24, John Polstra 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 de
Tom Bartol 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 e
On 8 April 1999 at 12:24, John Polstra 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
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
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 8 April 1999 at 11:49, John Polstra 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
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 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. Perha
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
In message 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 s
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
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
> 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
>> 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 f
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
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 dep
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 c
>> 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:
> 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
>> 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 o
* From: Chuck Robey
* 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 Uns
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
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:
>
> > 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/X
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
On Wed, 7 Apr 1999, John Polstra wrote:
> In article , Jeroen
> Ruigrok/Asmodai 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 progressi
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+(++)
* From: John Polstra
* 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 Pols
In article <19990408040432.a74...@nagual.pp.ru>,
Andrey A. Chernov 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-loop
In article , Jeroen
Ruigrok/Asmodai 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 source
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
> > > kerne
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 stil
"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 fi
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]
>
In article <19990407221941.a91...@nagual.pp.ru>,
Andrey A. Chernov 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 remove
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
"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.
60 matches
Mail list logo
