[Fedora-directory-users] notes on building fds in etch and a failed build question
Rich Megginson
rmeggins at redhat.com
Wed Feb 20 00:50:16 UTC 2008
Ryan Braun wrote:
> I've been working a little bit towards setting up a build environment for fds
> in debian.
> I've never actually built anything this complex, and in general
> my compiling experience is somewhat lacking. I'm trying to follow the write
> up at http://directory.fedoraproject.org/wiki/Building . Which states you
> have to build the mozilla components first. Here's where it gets
> interesting.
>
> nspr and nss are already installed on the systems by default.
>
> ii libnspr4-0d 1.8.0.15~pre080131b-0etch1
> NetScape Portable Runtime Library
> ii libnspr4-dev 1.8.0.15~pre080131b-0etch1
> Development files for the NetScape Portable
> ii libnss3-0d 1.8.0.15~pre080131b-0etch1
> Network Security Service libraries
> ii libnss3-0d-dbg 1.8.0.15~pre080131b-0etch1
> Development files for the Network Security S
> ii libnss3-dev 1.8.0.15~pre080131b-0etch1
> Development files for the Network Security S
> ii libnss3-tools 1.8.0.15~pre080131b-0etch1
> Network Security Service tools
>
>
> But they have a goofy version number dictated by the xulrunner package.
>
> http://packages.debian.org/source/etch/xulrunner
>
> ywgbuild:/usr/src/dsbuild/meta/ds# pkg-config --modversion xulrunner-nss
> 1.8.0.13pre
> ywgbuild:/usr/src/dsbuild/meta/ds# pkg-config --modversion xulrunner-nspr
> 4.6.7
>
> Now, I'm not sure why nspr is reporting it's true version number, while nss
> is reporting the 1.8.0 version when it should be something like 3.10 or 3.11.
>
Because the debian etch nspr and nss are not "true" standalone NSPR and
NSS packages - they are designed to work with xulrunner. This is
similar to the situation in RHEL4 and older Fedora when nspr and nss
were "provided" by firefox, but not really useful for building other
apps to use them.
> And, I've been digging on the debian packages listings trying to figure out
> just which version nss is. Any idea how to pull the version number right out
> of the shared lib?
I'm not sure, but it looks to be a fairly recent NSS so that's ok.
> Anyhow I moved on to try and build the next component,
> svrcore.
>
> I had to do some fudging with pkg-config (ln -s xulrunner-nspr.pc nspr.pc and
> ln -s xulrunner-nss.pc nss.pc) in order for svrcore's configure to work
> (prolly a RH vs debian package naming issue).
>
The package for nspr should be called "nspr" (the real name) or
"libnspr4" (the name of the package in debian). "xulrunner-nspr" is
simply wrong.
At any rate, you don't have to jump through these hoops with ln -s. You
can just use
svrcore/configure --with-nspr-inc=/usr/include/nspr
--with-nss-inc=/usr/include/nss
I don't think you will have to use --with-nspr-lib and --with-nss-lib
since it should just find them in /usr/lib.
Use svrcore/configure --help to see all of the available options.
> So I ./configure --prefix=/opt/svrcore and it makes and make install's ok.
> I add /opt/svrcore/lib to ld.so.conf, and run ldconfig.
>
> ywgbuild:/opt/svrcore# strings /etc/ld.so.cache |grep svrcore
> libsvrcore.so.0
> /opt/svrcore/lib/libsvrcore.so.0
> libsvrcore.so
> /opt/svrcore/lib/libsvrcore.so
> ywgbuild:/opt/svrcore# pkg-config --modversion svrcore
> 4.0.4
>
> Next on the list is the mozldap library
>
> ywgbuild:/usr/src/mozldap-6.0.5/mozilla/directory/c-sdk# ./configure --enable-clu --with-sasl --with-svrcore --enable-optimize --disable-debug --prefix=/opt/mozldap
> works ok.
> But then make throws this
>
> gcc -o
> ntuserpin.o -c -pipe -ansi -Wall -pthread -O2 -fPIC -UDEBUG -DNDEBUG=1 -DXP_UNIX=1 -D_POSIX_SOURCE=1 -D_BSD_SOURCE=1 -D_SVID_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DLINUX=1 -Dlinux=1 -Di386=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETNAMEINFO=1 -DHAVE_SASL=1 -DHAVE_SASL_OPTIONS=1 -DLDAP_SASLIO_HOOKS=1 -D_REENTRANT=1 -DNET_SSL -DNO_LIBLCACHE -DLDAP_REFERRALS -DNS_DOMESTIC -DLINUX2_0 -DLINUX1_2 -DLINUX2_1 -DLDAP_TOOL_ARGPIN -DLDAP_TOOL_PKCS11 -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -I/usr/include/nss -I/usr/include/nspr -I/usr/include/nspr -I/usr/include/sasl -I../../../../../dist/public/ldap -I../../../ldap/include -I/opt/svrcore/include -I/usr/include/nspr -I/usr/include/nss
> ntuserpin.c
> c++ -o bin/ldapdelete ldapdelete.o common.o convutf8.o fileurl.o
> ldaptool-sasl.o argpin.o
> ntuserpin.o -L../../../../../dist/./lib -lssldap60 -lprldap60 -lldap60 -lldif60 -L../../../../../dist/lib -lsvrcore -lssl3 -lnss3 -lsoftokn3 -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lplc4 -lplds4 -lnspr4 -lsasl2 -ldl -lresolv -lpthread
> /usr/bin/ld: cannot find -lsvrcore
> collect2: ld returned 1 exit status
> make[2]: *** [bin/ldapdelete] Error 1
>
> ywgbuild:/tmp# strace -o out ld -l svrcore
> ld: cannot find -lsvrcore
> ywgbuild:/tmp# grep open out
> open("/etc/ld.so.cache", O_RDONLY) = 3
> open("/usr/lib/libbfd-2.17.so", O_RDONLY) = 3
> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
> open("a.out", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
> open("/usr/bin/../lib/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
> open("/usr/bin/../lib/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
> open("/usr/i486-linux-gnu/lib32/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1
> ENOENT (No such file or directory)
> open("/usr/i486-linux-gnu/lib32/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1
> ENOENT (No such file or directory)
> open("/usr/local/lib32/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
> open("/usr/local/lib32/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
> open("/lib32/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
> or directory)
> open("/lib32/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib32/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
> file or directory)
> open("/usr/lib32/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
> file or directory)
> open("/usr/i486-linux-gnu/lib/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1
> ENOENT (No such file or directory)
> open("/usr/i486-linux-gnu/lib/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT
> (No such file or directory)
> open("/usr/local/lib/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
> open("/usr/local/lib/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
> file or directory)
> open("/lib/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
> directory)
> open("/lib/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib/libsvrcore.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
> or directory)
> open("/usr/lib/libsvrcore.a", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
> or directory)
> open("/usr/share/locale/locale.alias", O_RDONLY) = 4
> open("/usr/share/locale/en_CA/LC_MESSAGES/ld.mo", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> open("/usr/share/locale/en/LC_MESSAGES/ld.mo", O_RDONLY) = -1 ENOENT (No such
> file or directory)
>
>
> So I'm not sure why ld doesn't want to look in /opt/svrcore/lib for the
> libsvrcore shared libs. it just looks in the default spots according to
> strace. Did I mess up somewhere?
>
> As a quick fix I just symlinked /opt/svrcore/lib/libsvrcore.(a|so) to /usr/lib
> and it built.
>
Again, you don't have to do this, you can build mozldap with
--with-svrcore=/opt/svrcore
> mozldap doesn't make install apparently, but creates a dist directory
>
Take a look at dsbuild - dsbuild/ds/mozldap
> symlinking all the built apps and libs. So I just
> copied /usr/src/mozldap-6.0.5/mozilla/dist to /opt/mozldap copying the files
> rather then preserving the symlinks.
>
> add /opt/mozldap/lib to ld.so.conf && ldconfig
> ywgbuild:/opt/mozldap/bin# strings /etc/ld.so.cache |grep mozldap
> /opt/mozldap/lib/libssldap60.so
> /opt/mozldap/lib/libprldap60.so
> /opt/mozldap/lib/libldif60.so
> /opt/mozldap/lib/libldap60.so
>
> So those libs look to be installed ok.
>
> I then hacked up a fedora mozldap.pc (the make process didn't generate one,
> but the mozldap.pc.in file is there..)
> ywgbuild:/tmp/usr/lib/pkgconfig# cat mozldap.pc
> prefix=/opt/mozldap
> exec_prefix=${prefix}
> libdir=${prefix}/lib
> includedir=${prefix}/include
> bindir=${prefix}/bin
> major=6
> minor=0
> submin=5
> libsuffix=60
>
> Name: mozldap
> Description: Mozilla LDAP C SDK
> Version: 6.0.5
> Requires: nspr >= 4.6 , nss >= 1.8.0.13pre
> Libs: -lssldap60 -lprldap60 -lldap60
> Cflags: -I${includedir}
>
> But again I end up in a spot where ld can't find the libs I just installed.
> So I symlynk'd everything in /opt/mozldap/lib to /usr/lib/
> Then ld -lssldap60 -lprldap60 -lldap60 wouldn't complain about not being able
> to find the libs anymore.
>
> Now for perl-ldap
>
> export LDAPSDKINCDIR="/opt/mozldap/include"
> export LDAPSDKDIR="/opt/mozldap"
> export LDAPSDKLIBDIR="/opt/mozldap/lib"
> export NSPRINCDIR="/usr/include/nspr"
> export NSPRLIBDIR="/usr/lib"
> export NSSLIBDIR="/usr/lib"
>
> make would puke complaining about missing ldap-standard.h
>
See how dsbuild/ds/perldap/Makefile does it.
> ln -s /opt/mozldap/public/ldap/ldap-standard.h /opt/mozldap/include/ldap-standard.h
>
> ywgbuild:/usr/src/perl-mozldap-1.5.2# make
> cc -c -I/opt/mozldap/include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.5\" -DXS_VERSION=\"1.5\" -fPIC "-I/usr/lib/perl/5.8/CORE" -DUSE_SSL
> API.c
> Running Mkbootstrap for Mozilla::LDAP::API ()
> chmod 644 API.bs
> rm -f blib/arch/auto/Mozilla/LDAP/API/API.so
> LD_RUN_PATH="/opt/mozldap/lib" LD_RUN_PATH=/opt/mozldap/lib
> cc -shared -L/usr/local/lib API.o -o blib/arch/auto/Mozilla/LDAP/API/API.so
> \
> -L/opt/mozldap/lib -lssldap60 -lprldap60 -lldap60 -L/usr/lib -lssl3 -lnss3 -L/usr/lib -lplc4 -lnspr4
> \
>
> chmod 755 blib/arch/auto/Mozilla/LDAP/API/API.so
> cp API.bs blib/arch/auto/Mozilla/LDAP/API/API.bs
> chmod 644 blib/arch/auto/Mozilla/LDAP/API/API.bs
> Manifying blib/man3/Mozilla::LDAP::Conn.3pm
> Manifying blib/man3/Mozilla::LDAP::Utils.3pm
> Manifying blib/man3/Mozilla::LDAP::Entry.3pm
> Manifying blib/man3/Mozilla::LDAP::LDIF.3pm
> Manifying blib/man3/Mozilla::LDAP::API.3pm
>
> So where I'm at now, using sysyem nspr and nss, built mozldap and installed
> to /opt/mozldap, built svrcore and installed to /opt/svrcore and built
> perl-ldap, not installing it anywhere.
>
> So I figured I would give the newer dsbuild a shot at building the directory
> server. And it cranks away for a while then comes back with a message
> complaining about ldap agent and snmp. I initiated dsbuild with just a make
> command with no options.
>
You should have used SVRCORE_SOURCE=1 MOZLDAP_SOURCE=1 PERLDAP_SOURCE=1
by default, it will attempt to build and install into /opt/fedora-ds
> Here are the snmp packages installed
> ywgbuild:/usr/src/dsbuild/meta/ds# dpkg -l|grep snmp
> ii libsnmp-base 5.2.3-7etch2
> NET SNMP (Simple Network Management Protocol
> ii libsnmp-perl 5.2.3-7etch2
> NET SNMP (Simple Network Management Protocol
> ii libsnmp9 5.2.3-7etch2
> NET SNMP (Simple Network Management Protocol
> ii libsnmp9-dev 5.2.3-7etch2
> NET SNMP (Simple Network Management Protocol
>
> I've sent the last portion of the build process to pastebin if you want to
> have a look at
>
> http://www.pastebin.org/20301
>
> but the guts of the issue is this
>
> 3]: Entering directory
> `/usr/src/dsbuild/ds/ldapserver/work/fedora-ds-base-1.1.0'
> /bin/sh ./libtool --tag=CC --mode=link gcc -g -o ldap-agent-bin
> ldap/servers/snmp/ldap_agent_bin-main.o
> ldap/servers/snmp/ldap_agent_bin-ldap-agent.o
> ldap/servers/slapd/ldap_agent_bin-agtmmap.o -lssldap60 -lprldap60 -lldap60 -lldif60 -lsasl2 -lssl3 -lnss3 -lsoftokn3 -lplc4 -lplds4 -lnspr4 -L/usr/lib -lnetsnmpmibs -lnetsnmpagent -lnetsnmphelpers -lnetsnmp -lm -ldl -lsensors -lwrap -lwrap
> gcc -g -o ldap-agent-bin ldap/servers/snmp/ldap_agent_bin-main.o
> ldap/servers/snmp/ldap_agent_bin-ldap-agent.o
> ldap/servers/slapd/ldap_agent_bin-agtmmap.o -lssldap60 -lprldap60 -lldap60 -lldif60 /usr/lib/libsasl2.so -lresolv -lssl3 -lnss3 -lsoftokn3 -lplc4 -lplds4 -lnspr4 -L/usr/lib /usr/lib/libnetsnmpmibs.so /usr/lib/libnetsnmpagent.so /usr/lib/libnetsnmphelpers.so /usr/lib/libnetsnmp.so -lcrypto -lm -ldl -lsensors -lwrap
> ldap/servers/snmp/ldap_agent_bin-ldap-agent.o: In function `init_ldap_agent':
> ldap/servers/snmp/ldap-agent.c:98: undefined reference to `CONTAINER_INSERT'
> collect2: ld returned 1 exit status
> make[3]: *** [ldap-agent-bin] Error 1
> make[3]: Leaving directory
> `/usr/src/dsbuild/ds/ldapserver/work/fedora-ds-base-1.1.0'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory
> `/usr/src/dsbuild/ds/ldapserver/work/fedora-ds-base-1.1.0'
> make[1]: *** [build-work/fedora-ds-base-1.1.0/Makefile] Error 2
> make[1]: Leaving directory `/usr/src/dsbuild/ds/ldapserver'
> make: *** [dep-../../ds/ldapserver] Error 2
> make[
>
> Any ideas?
>
Looks like perhaps NETSNMP_USE_INLINE is not defined for some reason -
it expects CONTAINER_INSERT to be defined inline, but it's not, and not
defined in any libraries either. Looks like on debian it expects you to
define NETSNMP_USE_INLINE=1 explicitly even though it looks as though it
was built that way. On RHEL/Fedora, it looks like the
NETSNMP_USE_INLINE is implicit.
> Ryan Braun
> Informatics Operations
> Aviation and Defence Services Division
> Chief Information Officer Branch, Environment Canada
> CIV: (204) 833-2500x2824 CSN: 257-2824 FAX: (204) 833-2524
> E-Mail: Ryan.Braun at ec.gc.ca
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20080219/df0587a5/attachment.bin>
More information about the 389-users
mailing list