I found out that all google:”Berkeley DB” binaries on Solaris x86 have (or had) problem whereby libraries are searched on /net directory.
# /usr/ccs/bin/elfdump -d /usr/lib/bdb/db_verify | grep 'R*PATH'  RUNPATH 0x225 /net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib  RPATH 0x225 /net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib
I read this and thought about compiling the attached source. But I couldn’t find x86 where google:”SunStudio” or gcc was installed.
A recent change to Solaris ELF files makes it possible to change the google:”runpath” of a dynamic executable
Then I read this.
elfedit can indeed modify the runpath in an object, but it is considerably more general than that. elfedit is a tool for examining and modifying the ELF metadata that resides within google:”ELF object”s.
So, I extracted google:”elfedit” and related libraries from internal google:”Nevada install” server onto Solaris 10. Maybe I’m showing my ignorance here. I couldn’t make it work on Solaris 10. It could have possibly worked although surely not supported.
So, I decided to hack the binaries. I was a little scared when google:”strings” command didn’t show it.
# /usr/bin/strings /usr/lib/bdb/google:"db_verify" | grep /net
But google:”GNU strings” can show it.
# /usr/sfw/bin/gstrings --target=elf32-i386 db_verify | grep /net /net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib
I used google:”GNU sed” to google:”stub out” runpath.
# gnused -i.backup 's|\/net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib| |' db_*