Greg Schafer wrote:
> IMHO, the only person lately who has shown the required levels of
> understanding, drive and commitment, is you Dan. You obviously care quite
> a lot about LFS. If I were a betting man, my money would be on you for
> sure :-)
I agree that Dan is doing well. His comments are
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> 1) Do as DIY does and make a ld-new in chapter 5 binutils
Why build something if you don't need to. ld --nostdlib -L/usr/lib
-L/lib works? It is not an undocumented switch.
> 3) Drop the wrapper script for gcc and instead of linking ld-ne
Miguel Bazdresch wrote these words on 01/26/06 18:28 CST:
> I believe there might be a mistake in the kdegraphics instructions in
> the SVN book:
The book operates under the pretense that *all* sources (including
downloaded patches) are in a common directory. Then the main source
tarball is unpac
Miguel Bazdresch wrote these words on 01/26/06 18:28 CST:
> I believe there might be a mistake in the kdegraphics instructions in
> the SVN book:
>
> [/tmp]$ tar xf /src/kdegraphics-3.5.0.tar.bz2
> [/tmp]$ cp /src/post-3.5.0-kdegraphics-CAN-2005-3193.diff .
> [/tmp]$ cd kdegraphics-3.5.0/
> [/tm
Tushar Teredesai wrote:
> Why build something if you don't need to. ld --nostdlib -L/usr/lib
> -L/lib works? It is not an undocumented switch.
No, not exactly. At least not from my tests. The -Wl,--verbose output
shows that it's still finding the ld-linux.so.2 in /tools, unless you
use the static
Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 01/26/06 19:35 CST:
>
>
>>The patch instruction in the book is convoluted though. I don't know if
>>it is right or not, but the instruction should be:
>
>
> Please read my earlier message. The instruction isn't/wasn't convoluted,
> it wa
Randy McMurchy wrote:
> Hi all,
>
> To the maintainer of the Anduin package/patches repo, FYI to everyone
> else.
>
> I realize there has been a restructuring, so, I'm wondering if this
> is intentional? And if so, why?
>
> [SSH] [EMAIL PROTECTED]: /srv/www/htdocs/anduin/sources > ls -l *
> lrwx
Bruce Dubbs wrote these words on 01/26/06 19:57 CST:
> Can you please send me the original patch? I'm curious.
Curious about what? :-)
That they changed it?
Or that it used a different installation path prefix?
You can see that it changed as my earlier post shows it modifying
less files than
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Tushar Teredesai wrote:
> > Why build something if you don't need to. ld --nostdlib -L/usr/lib
> > -L/lib works? It is not an undocumented switch.
>
> No, not exactly. At least not from my tests. The -Wl,--verbose output
> shows that it's sti
Tushar Teredesai wrote:
>
> The dynamic linker path comes from gcc's specs file. You will need to
> edit that or add --dynamic-linker=/lib/ld-linux.so.2 to the above
> flags.
It was still edited. That part never changed.
> :) In that case there was no need to go thru all the changes. Just
> movi
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Tushar Teredesai wrote:
> >
> > The dynamic linker path comes from gcc's specs file. You will need to
> > edit that or add --dynamic-linker=/lib/ld-linux.so.2 to the above
> > flags.
>
> It was still edited. That part never changed.
Strange.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bruno Haible wrote:
Alexander E. Patrakov wrote:
The answer "patch
glibc so that iconv transliterates the bullet to 'o'" is better (and in
fact this is doable), but I think that users of non-Glibc systems (or
old Glibc) will complain if this becomes the official answer.
Why should the
I wrote:
Is this patch a right solution?
Forgot to say: even if it is, it would be insane to require patched or
not-yet-released version of glibc just for viewing manual pages "the
right way" in locales such as pl_PL. A short-term distro-friendly
solution is also needed. Any ideas?
--
Ale
Alexander E. Patrakov wrote:
> >Why should they complain? They can use GNU libiconv. It transliterates the
> >bullet to 'o', like you wish.
>
> The "iconv" program from libiconv transliterates the bullet to ".",
> which is also acceptable.
libiconv converts the MIDDLE DOT to '.' and the BULLET and
Greg Schafer wrote:
> Temporary wrapper scripts? Hmmm, these are interesting changes to say the
> least. They look completely bogus. You actually tested this stuff before
> committing? Where is the enhanced sanity check needed to verify this
> crucial stage of the build method?
The approach has be
>From http://www.linuxfromscratch.org/~ircd/logs/cross-lfs-2006-01-26 :
08:02 <@jim> hey did you see the change the quadrata just made to LFS
08:02 <@jim> Is that a sound toolchain update?
08:03 <@mdh> what did he do?
08:03 <@jim> followed Greg's advice
08:06 <@mdh> I'm gonna have to take a look
0
On 1/25/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Greg Schafer wrote:
> > Temporary wrapper scripts? Hmmm, these are interesting changes to say the
> > least. They look completely bogus. You actually tested this stuff before
> > committing? Where is the enhanced sanity check needed to verify
Dan Nicholson wrote:
> Why is there no discussion going on about this? I've looked all over,
> and I can't find any analysis by you that suggests that these fixes
> are appropriate. I even went looking through the (not documented
> anywhere on the LFS site) IRC logs:
>
> http://www.linuxfromscra
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> taken care of by the startfile_prefix_spec.
>
> I intend to leave the static binutils and ld-new symlink in, so that we
> don't have to carry over the saved binutils dirs from chapter 5.
This won't work. gcc does not respect PATH. Unless y
On 1/25/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Temporary wrapper scripts? Hmmm, these are interesting changes to say the
> least. They look completely bogus. You actually tested this stuff before
> committing? Where is the enhanced sanity check needed to verify this
> crucial stage of the bu
Dan Nicholson wrote:
> The way it is right now, we still need to keep the pass 2 binutils.
> If you want to make a symlink in /usr/bin/ld, then you need
> -B/usr/bin/.
You're looking at the rendered version from last night and not at what's
currently in the book. Check out the following, then re-
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> > The way it is right now, we still need to keep the pass 2 binutils.
> > If you want to make a symlink in /usr/bin/ld, then you need
> > -B/usr/bin/.
>
> You're looking at the rendered version from last night and not a
Bruno Haible wrote:
As for the "iconv" program from glibc, the situation is worse. I have
prepared a patch against Glibc-2.3.6 (attached) that transliterates the
offending characters produced by Groff into their ASCII equivalents if
there is no any other suitable fallback. You can try it without
Dan Nicholson wrote:
> I'm looking at it. This has the DIY changes. I thought you said you
> were going back to the *startfile_prefix_spec way like CLFS?
Yes, I will be. The changes:
1) Use the CLFS style sed for the specs file, ie,
gcc -dumpspecs | \
perl -pi -e 's@/tools/lib/ld-linux-so.2@/
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> Yes, I will be. The changes:
>
> 1) Use the CLFS style sed for the specs file, ie,
Fine.
> 2) Because the startfile_prefix_spec is used, no -B is necessary for gcc
> and the wrapper can be dropped entirely.
>
> 3) The changes to binutils
On 1/26/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> How is the adjusted binutils being found? Is an adjusted binutils
> being installed? If you're doing the DIY static ld to
> /tools/bin/ld-new with symlink /usr/bin/ld -> /tools/bin/ld-new, then
> it will not be used unless you have -B/usr/bin
Alexander E. Patrakov wrote:
> >The ACUTE ACCENT part looks wrong.
>
> But libiconv also transliterates it to "'" :)
The correctness criteria for glibc are stronger than for libiconv, since
it's used by many more people.
It can also be a bug in libiconv, due to the fact that at the time when
I in
Dan Nicholson wrote:
> How is the adjusted binutils being found? Is an adjusted binutils
> being installed? If you're doing the DIY static ld to
> /tools/bin/ld-new with symlink /usr/bin/ld -> /tools/bin/ld-new, then
> it will not be used unless you have -B/usr/bin/.
Indeed. So the current setu
> So: what is the official recommendation upon formatting manual pages
> in non-ISO-8859-1 non-UTF-8 locales with the CVS version of Groff?
You might provide small locale-specific macro files loaded in addition
to -man which translate the problematic characters to something iconv
can digest correc
> > 1. An acute accent is not a quoting character. Anyone using an
> > acute accent for quoting is abusing this character.
>
> Agreed, Groff should be fixed. Also it probably should use Unicode
> bullets (not middle dots) for bullets.
I won't change the defaults. From the PROBLEMS file:
*
Jeremy Huntwork wrote:
> Greg Schafer wrote:
>> Temporary wrapper scripts? Hmmm, these are interesting changes to say the
>> least. They look completely bogus. You actually tested this stuff before
>> committing? Where is the enhanced sanity check needed to verify this
>> crucial stage of the buil
Greg Schafer wrote:
> I said it looks completely bogus, coz to me, it does look completely
> bogus! :-/ It might work for the task at hand, I dunno. But I haven't
> tested it, and I'm not likely to test it either, because I do not believe
> in using wrappers for toolchain components. IMHO wrapping
On Thu, 26 Jan 2006 07:47:51 -0800, Dan Nicholson wrote:
> I think this has been known for a long time. If this was wrong, why
> wasn't there any noise by the Toolchain Maintainer?
Ryan, if you're reading this you'll be honest with yourself and realize
I'm not flaming!
This is not meant as a fl
Jeremy Huntwork wrote:
> If this doesn't work, there's another idea, but I'm going to test this
> first.
This didn't achieve the expected results. However, another way has. This
currently passes all tests:
1) Do as DIY does and make a ld-new in chapter 5 binutils
2) Use the *startfile_prefix_spe
35 matches
Mail list logo
