Ag. D. Hatzimanikas wrote: > On Wed, Aug 01, at 09:15 Randy McMurchy wrote: >> Again, this is not to refute that we must look into the new port >> of libedit, I only wrote this as an FYI about the misconception of >> what ldd output means. > > I can't comment about this part, because I am not really sure, but for > the record, I always thought that every package that linked into a binary > is being used directly or indirectly.
Yes, of course it is used directly *or indirectly*. But that wasn't the purpose of my message. It appears that both you and Alex didn't understand the meaning of my message, so apparently I didn't explain well. I'll try again. Say package A has ldd output that shows that libB is linked into it. My point is that it may not be that package A actually has any need, not can use any functionality of libB. It only *could* mean that some other package that package A links into the build, linked libB into its build. Meaning that if the other package didn't link libB into its build, package A's build would be identically the same, with exactly no difference in functionality. So, moral is, just because a binary lists a library in its ldd output, it really doesn't mean a thing other than it is indirectly referenced. And that indirectness could be absolutely meaningless. Does this make better sense? > Another thing that I noticed before in the output I posted, is that > (although in my setup it seems right, because I don't have separate > partitions), and because we place the dash binary into /bin (root partition), > so _if_ we decide to keep libedit as dependency, then the note/warning > should consist of two parts. > > a. The actual warning about the possible conflicts with readline and > b. That if someone is going to use editline should place the libedit > libraries into /lib, if /usr is in a different partition. Yes, if there is conflicts with Readline, it *must* be mentioned. However, I'm not sure that we should be mentioning build notes for dependency packages on the target package instructions. A note on the target package's page to reference additional information on the Wiki, would be prudent however. Meaning that we probably shouldn't have build notes for package B on Package A's instructions. If it *is* so important that it needs to be mentioned, then package B should have its own page in BLFS. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
