On Thu, Mar 20, 2008 at 3:16 PM, Kick, Claus claus.kick@siemens.com wrote:
Did you try to hide Suns ld? (mv /usr/ccs/bin/ld /usr/ccs/bin/ld.sun)
Also worth considering blastwave : http://www.blastwave.org/
The blastwave package is what we are running in production, Solaris 10, though.
Just as an aside, the last time somebody asked a question about Blastwave, it had some evidence of horrible breakage. (Hopefully fixed by now.)
Anyway:
I don't see how hiding ld would help. Even if it did help, it's a pretty ugly hack.
First off, if the goal is
So, finally, maybe my problem is something really stupid but I do not find the solution to get my binaries valid with requested libraries statically compiled.
If you want something compiled static, giving --enable-dynamic makes no sense. Perhaps you should try "--disable-dynamic --enable-static"? You probably also want CFLAGS/LDFLAGS set so that you bomb out instantly upon use of shared objects. Probably LDFLAGS+='-Bstatic' and CFLAGS+='-static' (you seem to be using gcc) are a good start. (I wouldn't be surprised at all if you bomb out in configure with that...which means that your issues are in your underlying environment, not the OpenLDAP build.)
Second, the only real error I've seen in this thread is:
ldd: /usr/local/bin/ldapsearch: file has insecure interpreterELF
So check your interpreter, i.e. elfdump -i /usr/local/bin/ldapsearch. If you succeeded in being statically linked, it'd return no output. (Looks like that'll return "ELF." In other words, you're dynamically linking.)
BTW, it's hard to envision a legitimate use case for the situations you've shown so far. If you're just trying to "use openldap" you almost certainly don't want to go through all this convolution to avoid dynamic linking...