> Will egcs affect the size of the kernel or any other compiledcode?
Verses what other compiler?? Of course the compiler will affect the size
of any compiled code. It may do worse, or even better. Various -O
values will affect the size too.
> I read that the exception code can add a
On Wed, 29 Dec 1999 14:47:12 GMT, Jonathon McKitrick wrote:
> Will egcs affect the size of the kernel or any other compiledcode?
Yes. Try it out for yourself and have a look, or hunt the -current
mailing list archives.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
Will egcs affect the size of the kernel or any other compiledcode? I read
that the exception code can add a lot to the object size.
-=> jm <=-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Dec 06, 1999 at 11:33:57AM +0200, Maxim Sobolev wrote:
> Does anybody could clarify why egcs is still in the base tree after several
> months of gcc2.95.2 as base compiler? Users with disk space constrains
> (including me) would definitely love to see those 34 MB being freed...
Does anybody could clarify why egcs is still in the base tree after several
months of gcc2.95.2 as base compiler? Users with disk space constrains
(including me) would definitely love to see those 34 MB being freed...
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
On Tue, Nov 16, 1999 at 07:29:35PM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Pierre Beyssac writes:
> >Since in_cksum is used in several places (there's another optimized
> Isn't there one in libalias already ?
Right. I missed it because it's called PacketAliasInternetChec
In message <[EMAIL PROTECTED]>, Pierre Beyssac writes:
>Since in_cksum is used in several places (there's another optimized
>copy in libstand), a cleaner solution would be to put it in some
>library.
Isn't there one in libalias already ?
--
Poul-Henning Kamp FreeBSD coreteam membe
On Mon, Nov 15, 1999 at 05:59:23PM -0800, Kris Kennaway wrote:
> On Tue, 16 Nov 1999, Pierre Beyssac wrote:
> > I've checked, the answer is no: apparently, in_cksum() in routed/rdisc.c
> > is only called in two places, both with an even size.
>
> Can it hurt to pre-emptively fix it anyway in case
< said:
> Perhaps the above should be written as:
> sum += ntohs(*(u_char *)w << 8);
> to avoid the undefined union access (answer.us).
No. The IP checksum is defined in a manner which is
endian-independent. Adding calls to ntohs() would only confuse
matters further.
-GAWollma
On Tue, 16 Nov 1999, Pierre Beyssac wrote:
> On Tue, Nov 16, 1999 at 03:17:43PM +1100, Bruce Evans wrote:
> > On Mon, 15 Nov 1999, Pierre Beyssac wrote:
> > > - volatile u_short answer = 0;
> > > + union {
> > > + u_int16_t us;
> > > + u_int8_t uc[2];
> > > + } answer;
> >
> > This has
On Tue, Nov 16, 1999 at 10:58:06AM +0200, Sheldon Hearn wrote:
> The word ``union'' doesn't appear in style(9) and a 1 tab indent is used
> consistently in the examples of structs. Use 1 tab.
Right, I reread style(9) and I apparently misunderstood the following part
which only applies to code (m
On Tue, 16 Nov 1999 09:45:36 +0100, Pierre Beyssac wrote:
> > - volatile u_short answer = 0;
> > + union {
> > + u_int16_t us;
> > + u_int8_t uc[2];
> > + } answer;
> Uh, which one(s) do you mean exactly? The 4-space indented union
> (I just followed style(9))
The word ``un
On Tue, Nov 16, 1999 at 03:17:43PM +1100, Bruce Evans wrote:
> On Mon, 15 Nov 1999, Pierre Beyssac wrote:
> > - volatile u_short answer = 0;
> > + union {
> > + u_int16_t us;
> > + u_int8_t uc[2];
> > + } answer;
>
> This has indentation bugs.
Uh, which one(s) do you mean exac
On Mon, 15 Nov 1999, Pierre Beyssac wrote:
> On Mon, Nov 15, 1999 at 01:35:15PM -0500, Garrett Wollman wrote:
> > If, rather than casting pointers, the code used a union (containing
> > one u_int16_t and one array[2] of u_int8_t), the compiler would have
> > enough information to know about the a
On Mon, Nov 15, 1999 at 05:48:31PM +0100, Pierre Beyssac wrote:
> The problem is apparently due to the following code fragment:
>
> register u_short answer = 0;
> [...]
> /* mop up an odd byte, if necessary */
> if (nleft == 1) {
> *(u_char *)(&answer) = *(
On Tue, 16 Nov 1999, Pierre Beyssac wrote:
> > [in_cksum bugs]
> > There's another bug in sbin/routed/rdisc.c:in_cksum() on odd packet
> > sizes, albeit I'm not sure it's ever triggered (does routed ever
> > generate odd-size packets?).
>
> I've checked, the answer is no: apparently, in_cksum()
> [in_cksum bugs]
> There's another bug in sbin/routed/rdisc.c:in_cksum() on odd packet
> sizes, albeit I'm not sure it's ever triggered (does routed ever
> generate odd-size packets?).
I've checked, the answer is no: apparently, in_cksum() in routed/rdisc.c
is only called in two places, both wit
[in_cksum bugs]
Fix committed for ping.
There's another bug in sbin/routed/rdisc.c:in_cksum() on odd packet
sizes, albeit I'm not sure it's ever triggered (does routed ever
generate odd-size packets?). It's a portability bug (works only on
little-endian machines). I'll commit the same fix if the
:It's not a compiler bug, it's a source code bug.
:
:The C Language specifies that pointers to distinct types can be
:assumed, under certain conditions, never to alias one another. (This
:...
:Recent values of GCC make use of this obscure language feature to
:improve optimization. Essentially,
On Mon, Nov 15, 1999 at 01:35:15PM -0500, Garrett Wollman wrote:
> If, rather than casting pointers, the code used a union (containing
> one u_int16_t and one array[2] of u_int8_t), the compiler would have
> enough information to know about the aliases.
You're right, this seems to work even with
< said:
> Maybe I can at least commit the addition of "volatile" to the source
> code. That will work around that particular bug until egcs is
> fixed...
It's not a compiler bug, it's a source code bug.
The C Language specifies that pointers to distinct typ
>
> > Maybe I can at least commit the addition of "volatile" to the source
> > code. That will work around that particular bug until egcs is
> > fixed...
>
> FWIW, the newly committed gcc-2.95.2 doesn't "fix" the problem.
Are you sure? GCC-
On Mon, 15 Nov 1999 18:01:45 +0100, Pierre Beyssac wrote:
> Maybe I can at least commit the addition of "volatile" to the source
> code. That will work around that particular bug until egcs is
> fixed...
FWIW, the newly committed gcc-2.95.2 doesn't "fix"
On Mon, Nov 15, 1999 at 06:52:23PM +0200, Sheldon Hearn wrote:
> On Mon, 15 Nov 1999 17:48:31 +0100, Pierre Beyssac wrote:
> > I've discovered the following problem, either due to egcs or the
> > source code for in_cksum in ping, I'm not sure.
> See PR 13292.
Wow, T
On Mon, 15 Nov 1999 17:48:31 +0100, Pierre Beyssac wrote:
> I've discovered the following problem, either due to egcs or the
> source code for in_cksum in ping, I'm not sure.
Alas, you're not in virgin territory, Columbus. :-)
See PR 13292.
Ciao,
Sheldon.
To Unsu
I've discovered the following problem, either due to egcs or the
source code for in_cksum in ping, I'm not sure.
The symptom is that in_cksum() returns an invalid result on an
odd-size buffer, when compile optimization is on.
You can check this by trying "ping -s 65 localhost&q
On Sat, 13 Nov 1999, Marcel Moolenaar wrote:
> BTW: I also don't need inline images, but I find xemacs more appealing
> in an X env.
Funny ... I only find xemacs useful when *not* using X, because that's
where xemacs will do syntax coloring and emacs won't.
Followups redirected to -chat.
--
B
Peter Mutsaers wrote:
>
> >> "MM" == Marcel Moolenaar <[EMAIL PROTECTED]> writes:
>
> MM> After (by accident) compiling world (excluding kernel) with
> MM> optimization disabled (ie -O0) and installing the resulting
> MM> binaries, xemacs (21.1.7) coredumps with a bus error. I
>
>> "MM" == Marcel Moolenaar <[EMAIL PROTECTED]> writes:
MM> After (by accident) compiling world (excluding kernel) with
MM> optimization disabled (ie -O0) and installing the resulting
MM> binaries, xemacs (21.1.7) coredumps with a bus error. I
MM> recompiled and reinstalled xemacs
According to Kevin Street:
> this. My xemacs has been core dumping after each build and install of
> world the last couple of times I did it. I have not had time to
> investigate the real cause yet.
I got the same problem between 3.3-R and 3.3-STABLE as well. Recompiling fixed
it.
--
Ollivie
Marcel Moolenaar <[EMAIL PROTECTED]> writes:
> After (by accident) compiling world (excluding kernel) with optimization
> disabled (ie -O0) and installing the resulting binaries, xemacs (21.1.7)
> coredumps with a bus error. I recompiled and reinstalled xemacs and all
> was fine. Now, after build
Hi,
After (by accident) compiling world (excluding kernel) with optimization
disabled (ie -O0) and installing the resulting binaries, xemacs (21.1.7)
coredumps with a bus error. I recompiled and reinstalled xemacs and all
was fine. Now, after building and installing world (excluding kernel
again)
> look at gcc's behaviour. This has left me somewhat confused. I
> appear to have two complete copies of gcc - one in src/contrib/gcc and
> another in src/contrib/egcs/gcc.
WIP. src/contrib/egcs is the current home. It is moving to
src/contrib/{gcc,libio,libstdc++,etc.}. Afte
According to Peter Jeremy:
> That's the way I remembered things. What threw me is that I currently
> have two _different_ gcc directories, both claiming to be EGCS 1.1.2,
> and both being updated.
The main reason is that we don't lose history with the directory change. At
f
: > David O'Brien is working on this now but I think he's
: >suffering from gcc-induced insanity. :-)
Actually, I'd bet more on amd induced insanity rather than gcc. There
have been too many problems with amd of late...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
Peter Wemm <[EMAIL PROTECTED]> wrote:
>Peter Jeremy wrote:
>> I appear to have two complete copies of gcc - one in src/contrib/gcc
>> and another in src/contrib/egcs/gcc.
>src/contrib/gcc is where gcc used to live. Then along came egcs with a
>cygnus-style tree that e
Peter Jeremy wrote:
> The recent thread about the GCC optimiser prompted me to go and have a
> look at gcc's behaviour. This has left me somewhat confused. I
> appear to have two complete copies of gcc - one in src/contrib/gcc and
> another in src/contrib/egcs/gcc. Both of
The recent thread about the GCC optimiser prompted me to go and have a
look at gcc's behaviour. This has left me somewhat confused. I
appear to have two complete copies of gcc - one in src/contrib/gcc and
another in src/contrib/egcs/gcc. Both of them have README files
stating that the
d run. the program only attempts file i/o once the run is
complete.
i AM NOT going to submit the half a gig core file, generate your own!
in the past day or so, i have tested EVERY MX between 14 and 22.
since this is a f77 program, it could be the fortran compiler, egcs,
or the OS itself causing
I'm assuming that you are using egcs-1.1.2.
gcc-2.95 seems to work OK. It doesn't discard the initialization of
answer like egcs-1.1.2 does.
Dan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hi,
I just came across the problem with ping and egcs. If you do
# ping -s 57 localhost
PING localhost (127.0.0.1): 57 data bytes
^C
--- localhost ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
if the data size is even number, it works OK. I think that
the
r/obj/usr/src/tmp/usr/include/g++ -O -pipe
>-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config
>-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC
>-I/usr/obj/usr/src/tmp/usr/include
>-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/inc -nostdi
Hi,
The following seems to have slipped in over the last 24 hours. I'm
probably the last to see it, and it may already be fixed, but I don't
see any obvious commits:
c++ -c -I/usr/obj/usr/src/tmp/usr/include/g++ -O -pipe
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config
On Thu, May 13, 1999 at 09:32:06PM -0500, Thomas T. Veldhouse wrote:
> Have you tried using the C++ standard way? It works.
>
> #include
> #include
>
> using namespace std;
>
> Of course, there are many times you won't want to include the entire
> namespace.
e solution to get and install libg++? Or, is there a near-term
> fix for the egcs package?
>
> tomdean
>
>
> 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
.gz the will work with EGCS 1.1.2 / GCC 2.8.1 from
ftp://egcs.cygnus.com/pub/egcs/infrastructure/ (or maybe also
prep.ai.mit.edu)
> libstdc++ has some classes 'if 0'-ed out.
What from the ISO standard is missing from libstdc++?
> I have a project that uses the string class a
ion to get and install libg++? Or, is there a near-term
fix for the egcs package?
tomdean
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
By all means see if threaded apps with exceptions work
with the base installed egcs . I pointed out an application
which does not work, care to give an example of a
threaded / exception application which works with
the base egcs compiler?
--
Amancio Hasty
ha...@star-gate.com
To
On Fri, May 7, 1999, Amancio Hasty wrote:
> Is not a good idea to use the default egcs as it is configured to compile
> c++ programs which use threads and exceptions for instance Netscape's
> Eletrical Fire (A Java VM/Compiler) does not work.
Why not? I constantly compile C
Yes I would try out the one on the ports directory first for threaded
applications with exceptions.
--
Amancio Hasty
ha...@star-gate.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Hi,
On Fri, May 07, 1999 at 01:10:31AM -0700, Amancio Hasty wrote:
> Is not a good idea to use the default egcs as it is configured to compile
> c++ programs which use threads and exceptions for instance Netscape's
> Eletrical Fire (A Java VM/Compiler) does not work.
do you sugg
Is not a good idea to use the default egcs as it is configured to compile
c++ programs which use threads and exceptions for instance Netscape's
Eletrical Fire (A Java VM/Compiler) does not work.
--
Amancio Hasty
ha...@star-gate.com
To Unsubscribe: send mail to majord...@freebsd.org
Andreas Braukmann wrote:
> Hi there,
>
> ?... yesterday I decided, that it might be the right time to
> ?actually pull the 'egcs'-switch on my 4.0-current SMP-box.
> ?I cvsupped, built and installed the world, tweaked the
> ?kernel config (newbus) ...
> ?Th
Hi there,
... yesterday I decided, that it might be the right time to
actually pull the 'egcs'-switch on my 4.0-current SMP-box.
I cvsupped, built and installed the world, tweaked the
kernel config (newbus) ...
The transition was smooth, so far.
The question remained: ... how
On Thu, 6 May 1999, David O'Brien wrote:
> > the build of egcs. My understanding was that to bootstrap over the change
> > I should first (before the make world) do:
>
> VERY wrong. All you want to do is a normal ``make world'' (or ``make
> buildworld&#x
> the build of egcs. My understanding was that to bootstrap over the change
> I should first (before the make world) do:
VERY wrong. All you want to do is a normal ``make world'' (or ``make
buildworld'')
> # cd /usr/src/gnu/usr.bin/cc; make clean; make obj
> # m
I'm doing a make world for the first time since the egcs cutover (yeah
yeah, keep the flames to yourselves) and I encountered a rough spot with
the build of egcs. My understanding was that to bootstrap over the change
I should first (before the make world) do:
# cd /usr/src; make -DCL
> In article <199904282026.oaa13...@zen.alb.khoral.com>,
> Steve Jorgensen wrote:
> > > In article <199904271932.naa01...@zen.alb.khoral.com>,
> > > Steve Jorgensen wrote:
> > > > I cvsup'ed and installed yesterday morning it's
In article <199904282026.oaa13...@zen.alb.khoral.com>,
Steve Jorgensen wrote:
> > In article <199904271932.naa01...@zen.alb.khoral.com>,
> > Steve Jorgensen wrote:
> > > I cvsup'ed and installed yesterday morning it's the third
> > >
> In article <199904271932.naa01...@zen.alb.khoral.com>,
> Steve Jorgensen wrote:
> > I cvsup'ed and installed yesterday morning it's the third
> > cvsup I've done since egcs went in, so I know it's working
> > ok. Anyway, I deci
In article <199904271932.naa01...@zen.alb.khoral.com>,
Steve Jorgensen wrote:
> I cvsup'ed and installed yesterday morning it's the third
> cvsup I've done since egcs went in, so I know it's working
> ok. Anyway, I decided to update my XFre
I'm seeing the same problem on two different machines, one running -current and
the other 2.2.8-STABLE!
-christian
On 27-Apr-99 Steve Jorgensen wrote:
> I cvsup'ed and installed yesterday morning it's the third
> cvsup I've done since egcs went in, so I kn
I cvsup'ed and installed yesterday morning it's the third
cvsup I've done since egcs went in, so I know it's working
ok. Anyway, I decided to update my XFree86 installation,
and found that the port no longer works. As it compiles
An egcs optimizer bug caused incorrect tcp checksum recalculation in libalias
for the rewritten PORT command packet and the server subsequently discard the
packet.
The following piece of C code (from TcpChecksum() in alias_util.c)
u_short *ptr;
int sum, oddbyte;
oddbyte
I am running 4.0-current of April 12. 1999.
I just finished updating my ports after the change to egcs-2.91.66. I
know they were OK as they were, but, I wanted to eliminate all the gcc
compiled things. And, this was a good time.
I had to fix a couple of applications with bad code. Everything
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:
>>
In message
Kenneth Wayne Culver writes:
: I forgot the particular error, but I don't think I'm doing it right. Is
: there something that I have to do before I do a make world? Thanks.
Read src/UPDATING for a start. If the error isn't there, then please
post the error. We can't do anything with
> I forgot the particular error, but I don't think I'm doing it right. Is
The actual error would be most helpful, otherwise this is sort of
a waste of email. :(
> there something that I have to do before I do a make world? Thanks.
A make world, assuming that you're already ELF, should do it.
-
I'm not sure what I'm doing wrong here, but I still can't get the EGCS
make world to work properly
I just cvsupped like 20 minutes ago, and I typed make -DNOGAMES world.
I forgot the particular error, but I don't think I'm doing it right. Is
there something that I
On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote:
> > what's the name of the system compiler going to be, egcs or gcc, or cc?
> > And the C++ one?
>
> No change in names. cc/gcc and c++/g++/CC
>
> --
> -- David(obr...@nuxi.com -or- obr
At 09:37 AM 4/9/99 -0700, David O'Brien wrote:
The Only way I could get Jade to work with the new compiler
was with CFLAGS= -O -pipe
That is not so bad. Before EGCS, we would state that "-O" is the only
optimization that is know to always work and what we tell people to use.
In message Chuck Robey
writes:
: Keep recompiling, Warner, it does work.
Yup. My build world just finished, and now it works. Yippie!
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
On Fri, 9 Apr 1999, Warner Losh wrote:
>
> OK. I've done two make worlds. One on April 2 or 3 and One on April
> 8th. I'm still getting the C++ error for simple C++ programs. Do I
> need to do yet another one to fix the problem? I'm doing one anyway,
> but am confused because I thought this
On 9 Apr 1999, Joel Ray Holveck wrote:
# > I've found where this problem is coming from. It's in
# > emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the
# > version number contained in __FreeBSD__, checking for 1, 2 and 3. Of
# > course, -current uses 4. I have found th
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
> /usr/lib/libc.so.3 (0x28527000)
I know for certain that libintl is gcc.
Will go and do recompilations of all stuff this weekend *sigh* ;)
In my case (it seems all libs compiled under egcs - exactly when jade
compiled):
/usr/local/bin/jade:
libstyle.so.1 => /usr/local/lib/lib
> The Only way I could get Jade to work with the new compiler
> was with CFLAGS= -O -pipe
That is not so bad. Before EGCS, we would state that "-O" is the only
optimization that is know to always work and what we tell people to use.
Mike Smith has written about this many time
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
> I've found where this problem is coming from. It's in
> emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the
> version number contained in __FreeBSD__, checking for 1, 2 and 3. Of
> course, -current uses 4. I have found that you can check for __FreeBSD__ >=
> 3, and it
OK. I've done two make worlds. One on April 2 or 3 and One on April
8th. I'm still getting the C++ error for simple C++ programs. Do I
need to do yet another one to fix the problem? I'm doing one anyway,
but am confused because I thought this had been fixed (or would be
fixed by two build wor
9:18 PM
To: Steve Price
Cc: Peter Jeremy; curr...@freebsd.org; po...@freebsd.org
Subject: Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
> You are absolutely right. I just tried the new version of emacs
> that I built on my pre-egcs box and it doesn't work on that b
>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
0)
> ??? libc.so.3 => /usr/lib/libc.so.3 (0x28527000)
>
> I know for certain that libintl is gcc.
>
> Will go and do recompilations of all stuff this weekend *sigh*? ;)
> ?
In my case (it seems all libs compiled under egcs - exactly when jade
compiled):
/usr/local/bin/jade:
?
In message <19990408122607.a19...@nuxi.com> "David O'Brien" writes:
: > ===> rpcsvc
: > rpcgen -C -h -DWANT_NFS3 /home/imp/FreeBSD/src/include/rpcsvc/key_prot.x -o
key_prot.h
: >
/home/imp/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:
On 08-Apr-99 David O'Brien wrote:
>> > Something broken in new egcs c++ compiler - jade doesn't work with
>> > following symptoms (checked on two machines).
>>
>> Apr 7 20:26:04 daemon /kernel: pid 61135 (jade), uid 0: exited on
>> signal
>&
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
> You are absolutely right. I just tried the new version of emacs
> that I built on my pre-egcs box and it doesn't work on that box
> either. This definitely doesn't appear to be anything caused by
> changing to egcs. Not that it matters much but for grins I just
> b
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
1 - 100 of 375 matches
Mail list logo
