On 3/1/12 11:43 AM, Qrux wrote:
> 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:
I'm saying that if you are compiling the libs and binaries, it should
conform to the configuration of your toolchain. I say 'should' because
it's wise to allow a small margin for corner cases in a user's personal
build, but honestly if it doesn't conform then something is broken.
> None of that seems relevant to the ssl-engine/libgost.so issue.
Why? It's exactly the same principle. Run ldd on ssl-engine/libgost.so
and see what you get.
> [~/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"
You appear to be searching after you've already configured it to build:
~/openssl-1.0.0e $ grep -r lib64 .
./CHANGES: have names other than "lib", for example "/usr/lib64"
which some
./util/shlib_wrap.sh: eval
$rld_var=\"/usr/lib64'${'$rld_var':+:$'$rld_var'}'\"
~/openssl-1.0.0e $ grep ENGINESDIR include/openssl/opensslconf.h
#define ENGINESDIR "/usr/local/ssl/lib/engines"
>> 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?
Everything. It's the same principle.
> I think you're still speaking hypothetically at this point, because the
> source seems to point to hardcoded paths.
1. It doesn't. did you grep for lib64?
2. Even if it did, hard coded paths are easy to change when you find them.
>> 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
Must is a strong word. The links themselves were a workaround - most
mainstream distros do it the real way and offer multilib. Which means
that both lib and lib64 are real directories. Actually, even pure64 with
real lib and lib64 directories is better. It forces you to be careful
about how you build and install your packages.
> 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?
That stuff is set when it configures for your system.
> 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?
No, I don't use LFS or BLFS except as an occasional reference, comparing
notes, so to speak.
> 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)?
I haven't built BIND in a long while since I haven't needed it, but for
OpenSSL and all others, again it's just a matter of making sure your
toolchain is configured correctly.
>
> 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."
Tabling it because of the precompiled binaries is about the only reason
to table it. What you are suggesting is overkill - 95% of the packages
you build will be just fine if you configure your toolchain to only use
lib. There will be some outside cases that will try to stick stuff in
lib64, but most of those you can just move to lib. Anything that is
hard-coded can be discovered by a careful build process and
re-hard-coded to a working path, but again, most everything will "just
work".
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
