> Ok, ignore the last message... I misunderstood that you meant getting
> all the .spec files set so the optflags settings were always passed
> down (and making sure --target i[456]86 actually worked)
>
> Sorry for my confusion :)
No problem!
Enclosed in this letter are the two patches necessar
hi,
it'd be nice to see in the updates directory since it was big problem
for many people.
http://www.freshmeat.net/news/2000/04/26/956756732.html
-- lfarkas
"The only thing worse than not knowing the truth is
ruining the bliss of ignorance."
--
To unsubscribe:
mail -s unsubscribe [EMAIL P
While trying to recompile egcs-1.1.2-30, I noticed it didn't quite build
right. There were a few shared libraries that it didn't compile but yet
still wanted to put into packages, and at one point it tried to use the
new g++ compiler while still mostly configured for the old one. (Plus,
it would
Wow, thanks for all the info, everyone!
I think I'm still going to go through all the work of compiling
i586/i686 versions of thingsI want to set up a network file server
that contains Linux installations for i386/i486/i586/i686, and allow
desktop clients to mount the appropriate architecture
>
> I would imagine that just compiling ghostscript for i686 isn't enough;
> one would also have to recompile things it depends on (like libc) in
> order to really tell whether there was an improvement.
>
But when you compile benchmarks (even those who make minimal use of
the library) you find
> I would imagine that just compiling ghostscript for i686 isn't enough;
> one would also have to recompile things it depends on (like libc) in
> order to really tell whether there was an improvement.
I do not think recompiling libc will make a noticible difference either;
any time ghostscript s
>
> Hello all! I searched the mailing list archives and found a few
> discussions of this topic, way back when, but there weren't any
> satisfactory answers. I'm wondering...why does RedHat not natively
> support i586 and i686 builds? (They do in the kernel, but that appears
> to be the *only*
I would imagine that just compiling ghostscript for i686 isn't enough;
one would also have to recompile things it depends on (like libc) in
order to really tell whether there was an improvement.
In any case, if I go through the work to get the source RPMs to produce
i586 and i686 code, does anyon
Steven Boswell wrote:
> about them. But is that the kind of change RedHat even wants? They're
> not supporting it now; do they have a good reason that hasn't occurred
> to me?
Not many packages really benifit from the optimizations.
The kerenel was only split in the 6.x series (I think)
Prior
Hello all! I searched the mailing list archives and found a few
discussions of this topic, way back when, but there weren't any
satisfactory answers. I'm wondering...why does RedHat not natively
support i586 and i686 builds? (They do in the kernel, but that appears
to be the *only* place.)
I l
edit /usr/lib/rpm/macros, go to the commented line that says:
# Boolean (i.e. 1 == "yes", 0 == "no") that controls whether files
# marked as %doc should be installed.
#%_excludedocs
and make it:
%_excludedocs 1
Maximum RPM is out of date.
Matt
On Thu, Apr 27, 2000 at 01:5
Hi,
I just tried to change the Red Hat Boot disk to not install the documentation
files.
I thought this would be quite simple - gunzip netstg2.img, mount it as loopback
device, edit usr/lib/rpm/rpmrc and add the following line:
excludedocs: 1
(This option is documented in Maximum RPM (rpmrc-f
12 matches
Mail list logo
