Randy McMurchy wrote:
Alexander E. Patrakov wrote these words on 12/26/05 20:29 CST:
Randy McMurchy wrote:
+<note><para>The instructions above don't create non-wide-character Ncurses
+libraries since nothing in LFS and BLFS would link against them at runtime.
What does LFS and BLFS have to do with it? Is LFS built with the
expectation that only LFS and BLFS packages will ever be built
on top of LFS? And that only they will be supported?
"in LFS and BLFS would link" should be changed to "ever links".
If the sentence cannot be changed to this because it would then
be untrue, then the libraries need to be built.
Build e.g. Screen-4.0.2 on top of the UTF-8 LFS to see what I mean, or
read the Readline page. It wants -lcurses, and gets linked to
libncursesw. If you build everything from source (even beyond BLFS),
everything that wants some form of curses gets linked to libncursesw.
The only way to obtain a program that shows "libncurses.so.5" in the ldd
output is to install a binary package.
Then you should be able to change the text to what I recommended.
Which is "since nothing ever links against them at runtime".
Nothing except binary-only packages :) Do we support them in LFS?
+If you must have such libraries because of some binary-only application,
+build them with the following commands:</para>
+<screen role="nodump"><userinput>make distclean &&
+./configure --prefix=/usr --with-shared --without-normal \
+ --without-debug --without-cxx-binding &&
Noted that the previous configure line didn't include
--without-cxx-binding and the description is commented out. Should
it be included here?
--without-cxx-binding is included here because this binding builds only
a static library, which cannot be needed for satisfying dependencies of
a binary package.
Then why isn't it used in the previous context building the 'wide'
version of the library? This is for my edification only.
The reader may want to install some package that needs that binding, by
compiling the package from source. The linker will use the
/usr/lib/libncurses++.a library then. The difference here is "building
from source" (may need this library at compilation time) vs "installing
a binary-only app" (already statically linked to libncurses++.a). There
is no way to link to libncurses++ dynamically.
+<filename class="libraryfile">libncurses</filename>
+(really, <filename class="libraryfile">libncursesw</filename>)
+library.
Why can't we just say what it is? Why must there be one library
listed, with in parenthesis listing what is really linked to?
This is intended to be a demonstration how applications that at
compilation time want -lncurses get actually linked to libncursesw. If
you can write a better explanation how the /usr/lib/libncurses.so linker
script works, please do it.
It isn't so much a better explanation, it is just a more concise
explanation. Why not just say the libncursesw library? Why must
the libncurses library be mentioned?
Only as an example how the linker script works. I think that having at
least one example is important, but please feel free to disagree with
me. Changing to -lncursesw and removing the "really..." note also
produces a correctly-linked readline library, but doesn't serve as an
example.
Proper solution: rewrite the code so that it doesn't make the mentioned
assumptions. Too hard for me.
Then, can it be reworded so that it doesn't indicate that LFS is
not implementing the proper solution? :-)
How about this?
This patch makes the assumptions valid again by falling back to English
messages when a multibyte locale is in use.
Dead keys?
http://en.wikipedia.org/wiki/Dead_key
Should it be that a (what I believe to be a fairly literate) English
speaker/writer/reader needs to reference an alternate source to
figure out what is being said? How would non-native English speakers
absorb this language?
MSDN explains the concept, I think that we should do that also.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
