Alexander E. Patrakov wrote:
> Greg Schafer wrote:
>> Hmmm, interesting. Is this a FSF or HJL thing or both? I've just noticed
>> that Binutils-pass2 also has --disable-nls. Hmm, OK. That is certainly
>> good reason to pass '--disable-nls'.
>
> This is at least for HJL. Not tested with FSF.
I've
Jeremy Huntwork wrote:
Alexander E. Patrakov wrote:
3) It is an optional dependency of Man-DB (to be used instead of Man
in the UTF-8 branch of the LFS book)
Hrm? Has there been some decision there I've missed?
No decision yet, but a proposal :) UTF-8 branch of the book doesn't
exist yet,
Greg Schafer wrote:
Alexander E. Patrakov wrote:
No, it was added deliberately in order to avoid binutils dependency on
the host gettext.
So Binutils won't build with NLS if Gettext is missing on the host?
Right.
Hmmm, interesting. Is this a FSF or HJL thing or both? I've just noticed
th
Alexander E. Patrakov wrote:
> No, it was added deliberately in order to avoid binutils dependency on
> the host gettext.
So Binutils won't build with NLS if Gettext is missing on the host?
Hmmm, interesting. Is this a FSF or HJL thing or both? I've just noticed
that Binutils-pass2 also has --di
Alexander E. Patrakov wrote:
3) It is an optional dependency of Man-DB (to be used instead of Man in
the UTF-8 branch of the LFS book)
Hrm? Has there been some decision there I've missed?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
U
Archaic wrote:
> On Wed, Aug 24, 2005 at 12:13:07PM +1000, Greg Schafer wrote:
>>
>> "This disables internationalization as i18n is not needed for the temporary
>> tools."
>
> This is an accurate statement.
True.
But it's not accurate in the context I described. If it's to stay it
should at le
Bruce Dubbs wrote:
Personally, I would like to use the ping and perhaps ping6 programs from
iputils and move ncftp from blfs to lfs. ncftp has no prereqs.
Why ncftp? I vote for Lynx for the following reasons:
1) It would also allow the reader to read the BLFS book :)
2) It supports HTTP
3) It
Greg Schafer wrote:
Hi
The explanation in Ch 5 Binutils Pass1 for --disable-nls says:
"This disables internationalization as i18n is not needed for the temporary
tools."
This is misleading because only the Pass1's of Binutils and GCC are passed
`--disable-nls'. For the statement to be accurate
On Wed, Aug 24, 2005 at 12:13:07PM +1000, Greg Schafer wrote:
>
> "This disables internationalization as i18n is not needed for the temporary
> tools."
This is an accurate statement. It does not say we need to pass this
everywhere, not does it say we are specifically avoiding i18n in chapter
5. I
Hi
The explanation in Ch 5 Binutils Pass1 for --disable-nls says:
"This disables internationalization as i18n is not needed for the temporary
tools."
This is misleading because only the Pass1's of Binutils and GCC are passed
`--disable-nls'. For the statement to be accurate, `--disable-nls' woul
On Wed, 24 Aug 2005, Ken Moffat wrote:
On Tue, 23 Aug 2005, Jim Gifford wrote:
No problems Ken. But what do you think of my reasoning on the error about
the different symlink names for ld?
At the moment, that sounds plausible (I've just posted about the perl script
bailing out). I used to
Ken Moffat wrote:
> Since
> LFS is all about learning, anybody like to point me to a HOWTO on
> learning to read what the book says, rather than what I think it says ?
Right after I finish this new compiler I'm working on -- RPM: Read
Programmer's Mind. :)
-- Bruce
--
http://linuxfromscra
Archaic wrote:
> On Tue, Aug 23, 2005 at 09:23:40AM +0200, Dan Osterrath wrote:
>
>>http://www.securitytracker.com/alerts/2005/Aug/1014744.html
>
>
> Lovely. Right after a BLFS release. :(
>
> Bruce, are there going to be any attempts at maintaining an errata page
> for BLFS?
Not right now, bu
Jim Gifford wrote these words on 08/23/05 18:48 CST:
> I know you have compiled them, but have you tested their
> functionality.
Yes.
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
18:49:00 up 143
Randy,
I know you have compiled them, but have you tested their
functionality. Just to give you a scenario I ran into with cross-lfs.
Ping compiled ok, but when ran gives a bus error.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://li
On Tue, 23 Aug 2005, Jim Gifford wrote:
No problems Ken. But what do you think of my reasoning on the error about the
different symlink names for ld?
At the moment, that sounds plausible (I've just posted about the perl
script bailing out). I used to have a --disable-multilib in my scripts,
On Tue, 23 Aug 2005, Ken Moffat wrote:
Sack-cloth and ashes time. I missed the "slibdir=/lib" part. Since LFS is
all about learning, anybody like to point me to a HOWTO on learning to read
what the book says, rather than what I think it says ?
Thanks for the clue, Jim.
So, now I'll co
No problems Ken. But what do you think of my reasoning on the error
about the different symlink names for ld?
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.or
Hi all,
Just an update for anyone interested. I've got many packages built
using the GCC-4 branch of LFS. Included so far is a functional KDE
desktop, some multimedia stuff, pdf viewer, everything it takes to
use subversion and render the LFS books, printing capability using
CUPS, Samba support an
On Tue, 23 Aug 2005, Jim Gifford wrote:
Ken,
You may want to see what I did in the book, I've gotten several builds
working on MIPS64 and Sparc64(minus the bootloader issue.) Everything went
into /lib no problem, I think this may be an x86_64 issue only. The reason I
say this is that the ld
Ken,
You may want to see what I did in the book, I've gotten several
builds working on MIPS64 and Sparc64(minus the bootloader issue.)
Everything went into /lib no problem, I think this may be an x86_64
issue only. The reason I say this is that the ld symlink on MIPS64 and
Sparc64 are the s
On Sat, 20 Aug 2005, Ken Moffat wrote:
On Fri, 19 Aug 2005, Jim Gifford wrote:
Ken, Ryan, Doug, and others
Do we need to make a change here for the pure64 build, or is further
testing needed?
Well, I've got through this part now, using 20050821, building pure64
from my own pure64. The l
Still doesn't work on Sparc64 works on Sparc.
Netkit has been tested on all so it shouldn't be a problem.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/fa
M.Canales.es wrote:
IMHO, for LFS we need only "ping" for FHS compliance. It's possible to build
(and use) just Inetutil's ping on all archs?
Doesn't work on Sparc
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org
Jim Gifford wrote:
Matt,
Which direction do we want to go in.
At the moment, I'm seriously considering dropping inetutils and
replacing it with just 'ping' from iputils. As you outlined, none of
these packages are maintained (to the degree we require at least), so
it's really picking the
Jim Gifford wrote:
> Matt,
>Which direction do we want to go in.
>
> Removal of inetutils ->
> Replace with netkit_base and netkit_combo? (Same as what
> inetutils is)
> Pros - Works with all architectures(cross-lfs, known
> to be stable)
> Cons - Needs heavy patching
El Martes, 23 de Agosto de 2005 20:56, Jim Gifford escribió:
> M.Canales.es wrote:
> >IMHO, for LFS we need only "ping" for FHS compliance. It's possible to
> > build (and use) just Inetutil's ping on all archs?
>
> Doesn't work on Sparc
Debian have an inetutils ping for Sparc:
http://packages.de
El Martes, 23 de Agosto de 2005 20:09, Jim Gifford escribió:
> Matt,
> Which direction do we want to go in.
IMHO, for LFS we need only "ping" for FHS compliance. It's possible to build
(and use) just Inetutil's ping on all archs?
About "ftp", actually isn't a requisite for LFS. We could poin
Matt,
Which direction do we want to go in.
Removal of inetutils ->
Replace with netkit_base and netkit_combo? (Same as what
inetutils is)
Pros - Works with all architectures(cross-lfs, known
to be stable)
Cons - Needs heavy patching to work (
Randy McMurchy wrote:
> Still, seems that updating the book with valid URLs (in cases where
> there is one) is the prudent thing to do.
Yes, but its not a high priority. Probably worth a P4 in BZ. As an
editor updates a page, he should check all the links and update as
necessary.
> the libraw1
Bruce Dubbs wrote these words on 08/23/05 10:58 CST:
> Bernard Leak wrote:
>>The following links for optional dependencies for gst-plugins seem
>>to be broken:
>
> See:
> http://www.linuxfromscratch.org/blfs/view/cvs/introduction/packages.html
Still, seems that updating the book with valid URLs (
On 8/22/2005 21:22, Archaic wrote:
> On Mon, Aug 22, 2005 at 01:33:37PM -0400, Jason Gurtz wrote:
>>
>> available network connections. Hey, wouldn't it be cool if root could
>> arbitrate how many of each type (TCP, UDP, ICMP) of connection each
>> user/group had in each of its instance's heap.
>
Dnia 21-08-2005 18:28:08 +0200 William wrotki:
> Has anyone experienced the problem where the dynamic loader
> library is not included in the list of LIBS?
Yes, even when building GIMP. Broken binutils caused that behavior.
Stay away from early 2.16. I switched to older version and it
Greg Schafer wrote:
Matthew Burgess wrote:
Does anyone know why shared libraries need the execute bit set on them?
AFAICT they don't need it (except of course libc.so.6 and ld-linux.so.2).
Debian ship a whole distro with the shared libs all 644 (apart from those
2 aforementioned libs).
My
> Thanks for the info. I think this is more serious than the ftp
> issue. I couldn't remember what my partitions are laid out like so I
> thought I'd have a look...
>
> andy:~$ su
> Password:
> root:/home/andy# cfdisk
> Segmentation fault
> root:/home/andy#
>
> DOH!
> I edited the configure scr
35 matches
Mail list logo
