On Feb 29, 2012, at 10:46 PM, Jeremy Huntwork wrote:
> Just to be clear - the BIND code itself shouldn't care about lib or
> lib64.
What, specifically, are you addressing when you say "shouldn't care"? Are you
speaking theoretically about how BIND should be designed? Or practically,
based on knowledge of the source? Just to be clear, I'm specifically talking
about the ssl-engine/libgost.so issue found in r9066 and addressed in r9463.
Are you speaking in generalities about named's shared lib dependencies? My ldd
shows this:
# ldd /usr/sbin/named
linux-vdso.so.1 => (0x00007fffc9d5a000)
liblwres.so.80 => /usr/lib64/liblwres.so.80 (0x00007fab2ad92000)
libdns.so.81 => /usr/lib64/libdns.so.81 (0x00007fab2aa0e000)
libbind9.so.80 => /usr/lib64/libbind9.so.80 (0x00007fab2a802000)
libisccfg.so.82 => /usr/lib64/libisccfg.so.82 (0x00007fab2a5e1000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007fab2a22f000)
libisccc.so.80 => /usr/lib64/libisccc.so.80 (0x00007fab2a027000)
libisc.so.83 => /usr/lib64/libisc.so.83 (0x00007fab29dd2000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fab29bce000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fab299b1000)
libc.so.6 => /lib/libc.so.6 (0x00007fab2962a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fab2afa4000)
And, yes, it does seem fairly obvious that it's looking in /usr/lib64 because
the toolchain does. I'm sure if it were built against a toolchain that didn't
have the lib64 links in / and /usr, that it wouldn't look down those links.
But, I don't care about any of that. I just assume that if the toolchain
didn't include the links when BIND was built, it would find its dependencies
just fine in /{,usr}/lib.
* * *
None of that seems relevant to the ssl-engine/libgost.so issue. AFAICT,
libgost.so isn't any part of that ldd output. Google-ing this problem seemed
to suggest that named really wanted libgost.so in order to start, and that the
reason it didn't start in the jail was a lib that was missing--and just needed
to be copied from the root. I did so, and discovered that wasn't enough. I
guessed it might be the lack of lib64 links. I added them, and named was able
to start. I didn't stop to see if /lib64 or /usr/lib64 that made the
difference. I'd guess the latter, but I don't care. When I brought this up on
blfs-dev, Andrew picked it up and made his edit in r9463:
+cp /usr/lib/engines/libgost.so usr/lib/engines &&
+[ $(arch) = x86_64 ] && ln -sv lib
usr/lib64</userinput></screen>
According to the man-page on dlopen(), the heuristics are (assuming named is
ELF for you two):
1) look for DT_RPATH tag
2) look in LD_LIBRARY_PATH
3) look for DT_RUNPATH tag
4) use /etc/ld.so.cache
5) look in /lib, /usr/lib
This implied to me that the dlopen() was referencing libgost.so(*), and looking
explicitly in either /lib64 or /usr/lib64. To me, that diagnosis fits best,
since it ran on root but not in the jail, and the main relevant difference was
the existence of those libraries. /etc/ld.so.cache doesn't exist in the jail,
either. That may fix the issue, too--in lieu of the links--but I haven't tried
it. I'm guessing it won't, since ldconfig doesn't seem to incorporate
/usr/lib/engines.
This led me to make the connection that BIND might hardcode paths. Of course,
I can't be sure if it's a hard-coded path in BIND, or a hard-coded path in
openssl(**). I'm not even sure it's a hard-coded dlopen() path...But I brought
it up as a possibility in the spirit of
"things-which-might-break-if-lib64-links-were-gone". I assumed someone would
know for sure. The further we go, the more it appears no one has looked at the
source. So...
====
(*) I've now read through the relevant BIND and OpenSSL sources. Turns out
it's not BIND--it's OpenSSL. BIND just calls ENGINE_by_id("gost")...
[~/lfs/src/bind-9.8.1-P1] # grep -i "ENGINE_by_id.*gost" $(find . -name "*.c")
./lib/dns/opensslgost_link.c: e = ENGINE_by_id("gost");
(*) Still same issue; just different package. ENGINE_by_id() is really calling
ENGINE_ctrl_cmd()...It goes on. TL;DR - After running ./config, I get this:
[~/lfs/src/openssl-1.0.0e] # grep ENGINESDIR $(find . -name "*.c" -o -name
"*.h")
./crypto/engine/eng_list.c: if((load_dir =
getenv("OPENSSL_ENGINES")) == 0) load_dir = ENGINESDIR;
./crypto/opensslconf.h:#define ENGINESDIR "/usr/lib64/engines"
./include/openssl/opensslconf.h:#define ENGINESDIR "/usr/lib64/engines"
====
OpenSSL probably could be configured differently. In the CHANGES file, I see
this:
*) Add support for --libdir option and LIBDIR variable in makefiles. This
makes it possible to install openssl libraries in locations which
have names other than "lib", for example "/usr/lib64" which some
systems need.
I assume that you want to reverse the new default (this is as of 0.9.8), and
I'm guessing you'd do that through using --libdir. I don't have time to try
this. Point is...there are some apps which are running around with hardcoded
paths for dlopen(). And probably some that haven't noticed it's a BadThing(TM)
and tried to fix it like OpenSSL.
But, let this just serve as a proxy example of why keeping it around might be a
GoodThing(TM) until more is known. Yes, it looks like OpenSSL might be made to
work if the links weren't there by configuring it correctly for your build.
But I think one warning sign from one core package is enough to say that this
issue warrants a LOT of eyeballs and regression testing.
> Its need for the symlink in BLFS has to do with where existing
> library dependencies live and where the compiler and linker has been
> told to look.
...What does this have to do with the ssl-engine/libgost.so issue?
> It is possible that BIND's build system may also default
> to a lib64 location on x86_64 hosts, but that's rare for autoconf builds
> systems. In any case, that kind of thing is easily overwritten and the
> code itself shouldn't care.
I think you're still speaking hypothetically at this point, because the source
seems to point to hardcoded paths. Yes, autoconf builds are nice (when done
correctly). A few keys things aren't using autoconf. OpenSSL is one--although
they may move in that direction. I haven't kept up. Currently, they aren't.
Neither is Xen, though they are talking about moving to autoconf (that may not
fix the tools/firmware issue; that seems more related to to multi-lib)
> So the main reason for having lib64 as a symlink is for compatibility
> with pre-compiled binaries, drivers, etc.
Right. On its own, this arguments strongly suggests the lib64-related links
must be included at least until alternatives for the critical-path things are
found (e.g., disk drivers, video drivers, mgmt tools, etc).
> Part of why I personally prefer removing it has to do with the knowledge
> gained by doing so. If a package tries to install something to /lib64 -
> you know right away. Having the symlink(s) masks that.
Right. Seems like you could just rm -f /{,usr}/lib64 and build your build to
see if breaks anything that's compiled from source. And, by 'breaks', I mean,
passes its own tests. So, to clarify:
1) Are you speaking hypothetically or theoretically about BIND/OpenSSL?
2) If not, can you point me to the source that shows how OpenSSL is getting
around the #define ENGINESDIR when loading "gost" for BIND?
3) Also, if not, are you saying you had built your pure-64 LFS and then went on
to compile OpenSSL using blfs-svn, and then went on to build BIND, and
discovered that BIND worked--either because OpenSSL sets a different (non
lib64-related) path for ENGINESDIR or works around it in some other way?
3) Finally, if not, what is your system and how did you configure each (so
BIND/OpenSSL works without the /lib64 and /usr/lib64 links)?
In case my position is unclear, I'm just saying: "I think the lib64-related
changes should be tabled until a lot more eyeballs are committed to making sure
the change preserves functionality across a lot of dimensions, including 'bad'
apps with hardcoded paths, drivers, games, and multilib-dependent-systems. I
also think that regardless of how this tangent (BIND/OpenSSL) ends up--or any
other tangents, for that matter--it's a red flag that this situation may exist
in other places downstream of LFS. As such, it requires much oversight before
changing."
Q
p.s. -- On Feb 29, 2012, at 10:46 PM, Jeremy Huntwork wrote:
> It sounded to me as if you were expressing frustration with Andy and with
> the style of communication here. If that wasn't the case, then my mistake.
One can be simultaneously frustrated *and* still be rationally asking for
clarification--just like you seemed frustrated with me and my questions. If
you want to do any more "frustrated talking", let's take it off-line. I'll
concede that perhaps my tone could be construed as being short, and have
already extended an olive-branch to Andrew off-line.
Let's refocus on the technical issues.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
