Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
I am still puzzled why in my case the above export statement was needed, but anyway... Because a variable setting is only good within the current process; if you do not export (or setenv in C-shells) a variable, the child process(es) will not inherit it. When you build software, a lot of child processes get created; it does not normally happen within only one process. And, if we want to link against the custom ldap libraries: CXXFLAGS=${CXXFLAGS} -I/usr/local/openldap/include; export CXXFLAGS LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber; export LDFLAGS %configure options Please add -rpath /usr/local/openldap/lib64 to your LDFLAGS so that you do not have to resort to LD_LIBRARY_PATH or ld.so.conf hacks. export CPPFLAGS=-DLDAP_DEPRECATED %{optflags} ...?? What does -DLDAP_DEPRECATED signify? It sets the LDAP_DEPRECATED macro, which is likely to have a conditional statement somewhere in the code, like this: #ifdef LDAP_DEPRECATED.#endif ...or like this: #if defined (LDAP_DEPRECATED).#endif This is used by the C pre-processor (cpp(1)) to decide what to include / omit / expand during the source code pre-processing stage, before that code is passed onto the compiler back end. To know exactly what that particular macro setting does, you have to find it in the header or program files and see what logic is in there. The answer is in the code.___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 11/4/2013 4:20 μμ, a b wrote: Please add -rpath /usr/local/openldap/lib64 to your LDFLAGS so that you do not have to resort to LD_LIBRARY_PATH or ld.so.conf hacks. Hmm, it didn't work like that: LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber -rpath /usr/local/openldap/lib64; export LDFLAGS In config.log: gcc: unrecognized option '-rpath' But it worked as: LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber -R/usr/local/openldap/lib64; export LDFLAGS Thanks again for your help! :-) Cheers, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
Hmm, it didn't work like that: LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber -rpath /usr/local/openldap/lib64; export LDFLAGS In config.log: gcc: unrecognized option '-rpath' That means that ./configure is using the compiler front end (gcc) to link the executable, which is correct and good, but is using LDFLAGS to do that, which is a mistake. For linking with the front end, the ./configure script should be using CFLAGS: -Wl,-rpath,@LIBDIR@ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 11/4/2013 9:51 μμ, a b wrote: That means that ./configure is using the compiler front end (gcc) to link the executable, which is correct and good, but is using LDFLAGS to do that, which is a mistake. For linking with the front end, the ./configure script should be using CFLAGS: -Wl,-rpath,@LIBDIR@ You mean I should set: CFLAGS=${CFLAGS} -Wl/usr/local/openldap/lib64 -lldap -llber -rpath /usr/local/openldap/lib64; export CFLAGS ...rather than LDFLAGS ? -lldap and -llber remain in there as they were? And what is @LIBDIR@ ? How do we use it? By the way, why using LDFLAGS is a mistake and we should do it with CFLAGS? Regards, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On Wed, Apr 10, 2013 at 08:06:45AM +0300, Nikolaos Milas wrote: On 10/4/2013 12:33 πμ, Ruben Kerkhof wrote: There must be something broken in your setup, can you show us the same output as I just did? [root@vmres x86_64]# rpm -qf /usr/lib64/liblber.so openldap-devel-2.4.23-32.el6_4.x86_64 [root@vmres x86_64]# ls -l /usr/lib64/liblber* lrwxrwxrwx. 1 root root 10 Sep 21 2012 /usr/lib64/liblber-2.4.so.2 - liblber.so lrwxrwxrwx 1 root root 27 Mar 11 16:06 /usr/lib64/liblber.so - /lib64/liblber-2.4.so.2.5.6 Sorry I had misspelled the path to the library in my email. I ment ofc /usr/lib64/liblber.so. Your problem appears to be that the linker does not realize that it is suppose to link with this library. You can try this temporary solution, to see whether it fixes this: LDFLAGS=-lber ./configure your configure options here If this helps, it means that the ldap stuff needs to be fixed to take liblber into account. Aki Tuomi signature.asc Description: Digital signature ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
Without looking at the SRPM, it is difficult to diagnose the problem. I might look at it later, if I have some time. Please be advised that this SRPM is a third party contributed SRPM, not the canonical source package. The only package which could be con- sidered canonical would be one from either redhat or CentOS. For all intents and purposes, you might have uncovered a bug. /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libldap_r.so: undefined reference to `ber_sockbuf_io_udp' collect2: ld returned 1 exit status The link editor cannot find the ber_sockbuf_io_udp symbol. I need you to perform the following: ldd /usr/lib64/libldap_r.so nm /usr/lib64/*.so | fgrep ber_sockbuf_io_udp See if you can find out if any shared object library has this symbol in it. You can use nm(1) and fgrep(1) to accomplish that. If that symbol cannot be found, then we have an answer. $ ls -la /usr/lib64/ | grep ldap drwxr-xr-x. 4 root root 4096 Mar 11 16:06 evolution-openldap lrwxrwxrwx. 1 root root 10 Sep 21 2012 libldap-2.4.so.2 - libldap.so -rw-r--r-- 1 root root 781914 Mar 20 15:57 libldapbackend.a -rwxr-xr-x 1 root root 1151 Mar 20 15:57 libldapbackend.la -rwxr-xr-x 1 root root 379419 Mar 20 15:57 libldapbackend.so lrwxrwxrwx. 1 root root 12 Sep 21 2012 libldap_r-2.4.so.2 - libldap_r.so lrwxrwxrwx 1 root root 29 Mar 11 16:06 libldap_r.so - /lib64/libldap_r-2.4.so.2.5.6 lrwxrwxrwx 1 root root 27 Mar 11 16:06 libldap.so - /lib64/libldap-2.4.so.2.5.6 -rwxr-xr-x 1 root root 40320 Feb 22 09:49 libsmbldap.so.0 That you have libraries there means absolutely nothing, unfor- tunately. You are getting the error because the link editor can- not locate the ber_sockbuf_io_udp symbol during the link phase. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
The actual libs, as installed by any openldap package (or compiled from source), are (at /usr/lib or at /usr/lib64 or at custom paths): libldap.so and liblber.so. Now what? The .spec file and the Makefiles should be checked for -llber. -llber tells the link editor to look for liblber.so - the linker automatically prepends lib. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
[root@vmres x86_64]# cat /etc/ld.so.conf include ld.so.conf.d/*.conf /usr/local/berkeleydb/lib64 /usr/local/openldap/lib64 Forget ld.so.conf; properly linked binaries and libraries will never need it. [root@vmres x86_64]# ls -la /usr/local/openldap/lib64/liblber* lrwxrwxrwx 1 ldap ldap 20 Mar 20 17:06 /usr/local/openldap/lib64/liblber-2.4.so.2 - liblber-2.4.so.2.9.0 -rw-r--r-- 1 ldap ldap 160959 Mar 12 16:39 /usr/local/openldap/lib64/liblber-2.4.so.2.9.0 -rw-r--r-- 1 ldap ldap 101556 Mar 12 16:40 /usr/local/openldap/lib64/liblber.a -rw-r--r-- 1 ldap ldap 864 Mar 12 16:39 /usr/local/openldap/lib64/liblber.la lrwxrwxrwx 1 ldap ldap 20 Mar 20 17:06 /usr/local/openldap/lib64/liblber.so - liblber-2.4.so.2.9.0 It seems /usr/lib64 and /usr/local/openldap/lib64 are being mixed up here. If you want to link with libraries in /usr/local/openldap/lib64, you need: LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -rpath /usr/local/openldap/lib64; export LDFLAGS CPPFLAGS=${CPPFLAGS} -I/usr/local/openldap/include; export CPPFLAGS Which one is being linked in, /usr/lib64, or /usr/local/openldap/lib64/? It has to be one or the other, but not both. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 10/4/2013 10:44 πμ, Aki Tuomi wrote: LDFLAGS=-llber ./configure your configure options here OK, this worked! export LDFLAGS=-llber %configure options I am still puzzled why in my case the above export statement was needed, but anyway... And, if we want to link against the custom ldap libraries: CXXFLAGS=${CXXFLAGS} -I/usr/local/openldap/include; export CXXFLAGS LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber; export LDFLAGS %configure options The above worked as well and they are the very settings I had first tried and posted here, BUT I had not added the export statement! So, things look OK now. Thank you all for your kind assistance! Just one more question: Why in the spec file of pdns-3.1 EPEL SRPM we also set: export CPPFLAGS=-DLDAP_DEPRECATED %{optflags} ...?? What does -DLDAP_DEPRECATED signify? Thanks, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On Tue, Apr 09, 2013 at 05:15:37PM +0300, Nikolaos Milas wrote: On 8/4/2013 11:36 μμ, Nikolaos Milas wrote: ...But let's step back for a while. /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libldap_r.so: undefined reference to `ber_sockbuf_io_udp' collect2: ld returned 1 exit status ... This line here is the clue. You are missing -llber (/usr/lib64/llber.so) Best regards, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users signature.asc Description: Digital signature ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On Tue, Apr 9, 2013 at 4:15 PM, Nikolaos Milas nmi...@admin.noa.gr wrote: To make things clearer, I started again from scratch; I downloaded http://www.monshouwer.eu/**download/3rd_party/pdns-** server/el6/SRPMS/pdns-server-**3.2-1.el6.MIND.src.rpmhttp://www.monshouwer.eu/download/3rd_party/pdns-server/el6/SRPMS/pdns-server-3.2-1.el6.MIND.src.rpmand I tried to build in a new user account, with: $ cat ~/.rpmmacros %_topdir %(echo $HOME)/rpmbuild as I usually do when building. Now, I tried to build the above, WITHOUT ANY MODIFICATIONS WHATSOEVER, on CentOS 6.4 (kernel: 2.6.32-358.2.1.el6.x86_64) and it always fails at the same point (i.e. it can't find the standard ldap libraries, although they exist on the system - as I have described in the beginning of the thread): checking for ldap_set_option in -lldap_r... no checking for ldap_set_option in -lldap... no configure: error: ldap library (libldap) not found I think we should focus on solving the problem why we can't build with the unmodified SRPM, using standard system libraries. Hi Nikolaos, I haven't followed this thread closely, so I don't know what you're trying to accomplish, but powerdns is in the EPEL repo too. The src.rpm is at http://dl.fedoraproject.org/pub/epel/6/SRPMS/pdns-3.1-2.el6.src.rpm, try that one. Kind regards, Ruben ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 9/4/2013 5:30 μμ, Aki Tuomi wrote: This line here is the clue. You are missing -llber (/usr/lib64/llber.so) There is not such a lib (llber.so or lber.so or lldap.so or ldap.so) in any openldap installation either on CentOS/EL 5 or 6. If the process requires such libs, it's looking for something that may not exist. The actual libs, as installed by any openldap package (or compiled from source), are (at /usr/lib or at /usr/lib64 or at custom paths): libldap.so and liblber.so. Now what? Thanks, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On Tue, Apr 9, 2013 at 9:42 PM, Nikolaos Milas nmi...@admin.noa.gr wrote: There is not such a lib (llber.so or lber.so or lldap.so or ldap.so) in any openldap installation either on CentOS/EL 5 or 6. On my system (Scientific Linux 6.4, but that shouldn't matter) there is: [ruben@dev-ruben ~]$ rpm -qf /usr/lib64/liblber.so openldap-devel-2.4.23-31.el6.x86_64 [ruben@dev-ruben ~]$ ls -l /usr/lib64/liblber* lrwxrwxrwx. 1 root root 10 Apr 9 23:26 /usr/lib64/liblber-2.4.so.2 - liblber.so lrwxrwxrwx. 1 root root 27 Apr 9 23:26 /usr/lib64/liblber.so - /lib64/liblber-2.4.so.2.5.6 [ruben@dev-ruben ~]$ rpm -qf /lib64/liblber-2.4.so.2.5.6 openldap-2.4.23-31.el6.x86_64 And openldap-devel is a BuildRequires for that src.rpm, so both openldap-devel and openldap should be installed on your system. There must be something broken in your setup, can you show us the same output as I just did? Thanks, Ruben ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
2013/4/9 Nikolaos Milas nmi...@admin.noa.gr checking for ldap_set_option in -lldap_r... no checking for ldap_set_option in -lldap... no configure: error: ldap library (libldap) not found The mystery remains a mystery. Any ideas? That's probably a problem with your build setup: Please see my reply on the CentOS mailing list: http://lists.centos.org/pipermail/centos/2013-April/133977.html Best regards, Morten ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 10/4/2013 12:33 πμ, Ruben Kerkhof wrote: There must be something broken in your setup, can you show us the same output as I just did? [root@vmres x86_64]# rpm -qf /usr/lib64/liblber.so openldap-devel-2.4.23-32.el6_4.x86_64 [root@vmres x86_64]# ls -l /usr/lib64/liblber* lrwxrwxrwx. 1 root root 10 Sep 21 2012 /usr/lib64/liblber-2.4.so.2 - liblber.so lrwxrwxrwx 1 root root 27 Mar 11 16:06 /usr/lib64/liblber.so - /lib64/liblber-2.4.so.2.5.6 [root@vmres x86_64]# rpm -qf /lib64/liblber-2.4.so.2.5.6 openldap-2.4.23-32.el6_4.x86_64 I have installed both openldap and openldap-devel packages. Can't find anything broken. Note only that I have also installed ltb openldap packages, which however uses different paths to install libs etc, so it does not affect any system libraries: [root@vmres x86_64]# rpm -qa | grep openldap openldap-devel-2.4.23-32.el6_4.x86_64 openldap-ltb-2.4.34-1.el6.x86_64 openldap-2.4.23-32.el6_4.x86_64 openldap-ltb-debuginfo-2.4.34-1.el6.x86_64 [root@vmres x86_64]# cat /etc/ld.so.conf include ld.so.conf.d/*.conf /usr/local/berkeleydb/lib64 /usr/local/openldap/lib64 [root@vmres x86_64]# ls -la /usr/local/openldap/lib64/liblber* lrwxrwxrwx 1 ldap ldap 20 Mar 20 17:06 /usr/local/openldap/lib64/liblber-2.4.so.2 - liblber-2.4.so.2.9.0 -rw-r--r-- 1 ldap ldap 160959 Mar 12 16:39 /usr/local/openldap/lib64/liblber-2.4.so.2.9.0 -rw-r--r-- 1 ldap ldap 101556 Mar 12 16:40 /usr/local/openldap/lib64/liblber.a -rw-r--r-- 1 ldap ldap864 Mar 12 16:39 /usr/local/openldap/lib64/liblber.la lrwxrwxrwx 1 ldap ldap 20 Mar 20 17:06 /usr/local/openldap/lib64/liblber.so - liblber-2.4.so.2.9.0 Any ideas? Thanks, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
but it exited with an error: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix==/usr/local/openldap --exec-prefix==/usr/local/openldap --bindir==/usr/local/openldap/bin configure: error: expected an absolute directory name for --exec_prefix: =/usr/local/openldap error: Bad exit status from /var/tmp/rpm-tmp.WrpSHX (%build) That does not even make any sense: above, you are passing in --exec-prefix; but the error says --exec_prefix. That does not compute. Why it can't find the default system libraries (which are indeed in /usr/lib64/) ??? It's the first time this happens to me. I have built many packages (Postfix, Dovecot, Openldap, etc.) and I have never had a problem building using the default spec file. To know the answer to that question, you need to search config.log, and preferably post the LDAP excerpt from it here. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
Thanks for the reply. Please, see below. /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libldap_r.so: undefined reference to `ber_sockbuf_io_udp' As suspected, the link editor is not finding the symbols (function definitions) it needs to resolve bindings in the object file(s). What does your ~/.rpmmacros file looks like? While technically not necessary, CFLAGS must often contain -L and -R switches to work around buggy or incorrectly coded ./configure files.Ditto for LDFLAGS.Do you set CFLAGS and LDFLAGS? What do they look like? ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
You need to pass --libdir=/usr/local/openldap/lib64 on the %configure line. Tried that, but the same error occurred. I did not mean that literally, sorry for the confusion. What I meant is that you muss pass the equivalent of --libdir=/usr/local/openldap/lib64 by using --libdir=%{_libdir}, which is a special RPM built-in macro. What this means is that your ~/.rpmmacros file is either incorrect or non-existent. ~/.rpmmacros must exist before attempting to (re)build RPM packages, and it must be correct. That is not optional. Sample, working .rpmmacros file:%HOME %{expand:%%(echo $HOME)}%_topdir%{HOME}/devel/rpms%__printf /usr/bin/printf%MY_BASEopt/openldap%__python /%{MY_BASE}/bin/python%_defaultdocdir /%{MY_BASE}/share/doc%_prefix /%{MY_BASE}%_sysconfdir/etc/%{MY_BASE}%_mandir /%{MY_BASE}/share/man%_infodir /%{MY_BASE}/share/info%_localstatedir /var/%{MY_BASE} The above .rpmmacros file is configured to comply with the Linux Standards Base (LSB) Filesystem Hierachy Standard (FHS) I mentioned earlier. You should rebuild openldap RPM with the above .rpmmacros file sitting in your home directory. With it, the %{_libdir} macro should be set correctly by RPM, and it will be passed on the %configure line correctly; however, you might still need to append to, or override CFLAGS, CXXFLAGS, CPPFLAGS, and LDFLAGS, depending on whether the ./configure script works correctly or not. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
%_prefix/%{MY_BASE} I should also add that you should pick a top-level directory in opt, like for example blabla or some other generic name (usually your organization's name, acronym, or most preferrably, lower case version of your organization's stock symbol, if you have one), and all RPM's you build should end up in the following hierachy, I am using a made-up name blabla in the example: /opt/blabla/sbin/opt/blabla/bin/opt/blabla/lib/opt/blabla/lib64/opt/blabla/libexec/etc/opt/blabla/openldap/etc/opt/blabla/pdns/var/opt/blabla/openldap/var/opt/blabla/pdns With %MY_BASE (or more appropriately to this example, %BLABLA_BASE) being set to opt/blabla, all SRPM's one (re)builds from that point on should be able to correctly find their files under the /opt/blabla/ hierarchy. This includes libraries. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 22/3/2013 6:23 pm, a b wrote: I did not mean that literally, sorry for the confusion. What I meant is that you muss pass the equivalent of --libdir=/usr/local/openldap/lib64 by using --libdir=%{_libdir}, which is a special RPM built-in macro. Thanks for your assistance. Sorry, I am not a specialist in building apps, so instructions should be clear otherwise I have to experiment. :-( What this means is that your ~/.rpmmacros file is either incorrect or non-existent. Until now, I always use a simple: $ cat .rpmmacros %_topdir %(echo $HOME)/rpmbuild which has worked fine in many builds I have, and it works fine when I build pdns-server on CentOS 5. However, I see your point: I should set (in .rpmmacros) something like: %_libdir /usr/local/openldap/lib64 Yet, my earlier question remains: Can I set multiple paths, like: %_libdir /usr/lib64,/usr/local/openldap/lib64 ...? Is it supported? On 22/3/2013 6:06 pm, a b wrote: While technically not necessary, CFLAGS must often contain -L and -R switches to work around buggy or incorrectly coded ./configure files. Ditto for LDFLAGS. Do you set CFLAGS and LDFLAGS? What do they look like? I don't see any CFLAGS or LDFLAGS specified in the spec file. When I build (as an example) Dovecot, I use in the spec file (before ./configure): export CPPFLAGS=${CPPFLAGS} -I/usr/local/openldap/include export LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber Should I try the same here? You should rebuild openldap RPM with the above .rpmmacros file sitting in your home directory. I understand, however I don't want to mess around with this package, although I see your point and I think it's valid. I'll pass your suggestions to the LTB project maintainers as they are responsible for these builds. Thanks again and regards, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
Thanks for your assistance. You are welcome. Until now, I always use a simple: $ cat .rpmmacros %_topdir %(echo $HOME)/rpmbuild which has worked fine in many builds I have, and it works fine when I build pdns-server on CentOS 5. This works because you are redefining the top build directory to be your own account, and because it builds the RPM linked with default libraries in /usr/lib or /usr/lib64, depending on whether one is building on a 32- or 64-bit system (and what the compilers' switches are). However, I see your point: I should set (in .rpmmacros) something like: %_libdir /usr/local/openldap/lib64 Unfortunately, no. You should configure your .rpmmacros file with at least %prefix as in the earlier example .rpmmacros file. rpmbuild(1) will then automatically set %_libdir macro to /something/something/lib64 or /something/something/lib depending on whether one is building 32- or 64-bit. Since the SRPM, by definition, must build without changes on both 32- and 64-bit architectures, %_libdir must not be modified directly; in order to have it correctly set to /usr/local/openldap/lib64, %MY_BASE in the earlier example would have to be set to /usr/local/openldap. As you can see, this is not necessarily what you want in the long term, because it implies that any and all software would have to end up in /usr/local/openldap. Yet, my earlier question remains: Can I set multiple paths, like: %_libdir /usr/lib64,/usr/local/openldap/lib64 ...? Is it supported? As far as I am aware, no. Also, one is never supposed to pass /usr/lib, /usr/lib64, /lib, or /lib64 to the link editor. These paths are hard coded inside of the link editor binary, and providing them on the link line or anywhere else during compilation has undefined results. I don't see any CFLAGS or LDFLAGS specified in the spec file. What about %_smpflags or %optflags macros, are they referenced anywhere in the .spec file? When I build (as an example) Dovecot, I use in the spec file (before ./configure): export CPPFLAGS=${CPPFLAGS} -I/usr/local/openldap/include export LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber Should I try the same here? You can; sometimes that works, sometime it does not. It is a hit-and-miss. Actually, you could try the following in the .spec file; this assumes %_prefix=/usr/local/openldap in your .rpmmacros, since you wrote that you would rather not change it: O='$$O'; export O ORIGIN='$ORIGIN'; export ORIGIN CPPFLAGS=${CPPFLAGS} -I%{_prefix}/include; export CPPFLAGS LDFLAGS=${LDFLAGS} -L%{_libdir} -R${ORIGIN}:${ORIGIN}/../%{_lib}:${ORIGIN}/../../%{_lib}:%{_libdir}; export LDFLAGS CFLAGS=${CFLAGS} -Wl,-L%{_libdir},-R${ORIGIN}:${ORIGIN}/../%{_lib}:${ORIGIN}/../../%{_lib}:%{_libdir}; export CFLAGS CXXFLAGS=${CXXFLAGS} -Wl,-L%{_libdir},-R${ORIGIN}:${ORIGIN}/../%{_lib}:${ORIGIN}/../../%{_lib}:%{_libdir}; export CXXFLAGS %configure ... ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
CPPFLAGS=${CPPFLAGS} -I%{_prefix}/include; export CPPFLAGS LDFLAGS=${LDFLAGS} -L%{_libdir} -R${ORIGIN}:${ORIGIN}/../%{_lib}:${ORIGIN}/../../%{_lib}:%{_libdir}; export LDFLAGS CFLAGS=${CFLAGS} -Wl,-L%{_libdir},-R${ORIGIN}:${ORIGIN}/../%{_lib}:${ORIGIN}/../../%{_lib}:%{_libdir}; export CFLAGS CXXFLAGS=${CXXFLAGS} -Wl,-L%{_libdir},-R${ORIGIN}:${ORIGIN}/../%{_lib}:${ORIGIN}/../../%{_lib}:%{_libdir}; export CXXFLAGS I forgot, you are probably using GCC, are you not? If so, replace -R with -rpath. GNU of course has to be differ from any and all standards, just because it can! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 20/3/2013 8:38 μμ, a b wrote: What does config.log say regarding ldap? Thanks for the reply. Please, see below. Thanks, Nick === ... configure:18499: checking ldap.h usability configure:18499: g++ -c -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic conftest.cpp 5 configure:18499: $? = 0 configure:18499: result: yes configure:18499: checking ldap.h presence configure:18499: g++ -E conftest.cpp configure:18499: $? = 0 configure:18499: result: yes configure:18499: checking for ldap.h configure:18499: result: yes configure:18513: checking lber.h usability configure:18513: g++ -c -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic conftest.cpp 5 configure:18513: $? = 0 configure:18513: result: yes configure:18513: checking lber.h presence configure:18513: g++ -E conftest.cpp configure:18513: $? = 0 configure:18513: result: yes configure:18513: checking for lber.h configure:18513: result: yes configure:18526: checking for ldap_set_option in -lldap_r configure:18551: g++ -o conftest -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -lrt c$ /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libldap_r.so: undefined reference to `ber_sockbuf_io_udp' collect2: ld returned 1 exit status configure:18551: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | #define PACKAGE_URL | #define PACKAGE pdns | #define VERSION 3.2 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define YYTEXT_POINTER 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR .libs/ | #define HAVE_BOOST 1 | #define HAVE_BOOST_FOREACH_HPP 1 | #define HAVE_BOOST_PROGRAM_OPTIONS_HPP 1 | #define HAVE_BOOST_ARCHIVE_TEXT_OARCHIVE_HPP 1 | #define HAVE_LUA 1 | #define HAVE_LUA_H 1 | #define STDC_HEADERS 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GETOPT_H 1 | #define HAVE_LIMITS_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYSLOG_H 1 | #define HAVE_UNISTD_H 1 | #define TIME_WITH_SYS_TIME 1 | #define RETSIGTYPE void | #define HAVE_GETHOSTNAME 1 | #define HAVE_GETTIMEOFDAY 1 | #define HAVE_MKDIR 1 | #define HAVE_MKTIME 1 | #define HAVE_SELECT 1 | #define HAVE_SOCKET 1 | #define HAVE_STRERROR 1 | #define HAVE_STRCASESTR 1 | #define HAVE_LIBDL 1 | #define HAVE_LIBCRYPT 1 | #define HAVE_IPV6 1 | #define HAVE_LDAP_H 1 | #define HAVE_LBER_H 1 | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern C | #endif | char ldap_set_option (); | int | main () | { | return ldap_set_option (); | ; | return 0; | } configure:18560: result: no configure:18567: checking for ldap_set_option in -lldap configure:18592: g++ -o conftest -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -lrt c$ /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libldap.so: undefined reference to `ber_sockbuf_io_udp' collect2: ld returned 1 exit status configure:18592: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | #define PACKAGE_URL | #define PACKAGE pdns | #define VERSION 3.2 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define YYTEXT_POINTER 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR .libs/ | #define HAVE_BOOST 1 | #define HAVE_BOOST_FOREACH_HPP 1 | #define HAVE_BOOST_PROGRAM_OPTIONS_HPP 1 | #define HAVE_BOOST_ARCHIVE_TEXT_OARCHIVE_HPP 1 | #define HAVE_LUA 1 | #define HAVE_LUA_H 1 | #define STDC_HEADERS 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GETOPT_H 1 | #define HAVE_LIMITS_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYSLOG_H 1 | #define HAVE_UNISTD_H 1 | #define TIME_WITH_SYS_TIME 1 | #define RETSIGTYPE void | #define HAVE_GETHOSTNAME 1 | #define HAVE_GETTIMEOFDAY 1 | #define HAVE_MKDIR 1 | #define HAVE_MKTIME 1 | #define HAVE_SELECT 1 | #define HAVE_SOCKET 1 | #define HAVE_STRERROR 1 | #define HAVE_STRCASESTR 1 | #define
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 20/3/2013 8:25 μμ, a b wrote: You need to pass --libdir=/usr/local/openldap/lib64 on the %configure line. Tried that, but the same error occurred. %configure \ --sysconfdir=%{_sysconfdir}/powerdns \ --libdir=/usr/local/openldap/lib64 \ --with-sqlite3 \ --with-socketdir=/var/run/pdns-server \ --with-modules= \ --with-dynmodules=pipe gmysql gpgsql gsqlite3 ldap %{__make} Due to the fact that in the beginning it was: --libdir=%{_libdir} ...I am thinking I should use multiple paths, like: --libdir=%{_libdir},/usr/local/openldap/lib64 Is it supported? But ideally I would like to force the use of /usr/local/openldap/lib64 ONLY for LDAP libs. Can't I declare that explicitly somehow? Thanks, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 19/3/2013 8:13 μμ, Nikolaos Milas wrote: But, as I mentioned, it even fails without any change in the spec file, simply trying to build with the standard CentOS 6 OpenLDAP packages. In that case, it should be using the default system lib dir: In the meantime, I tried building PowerDNS 3.2 on CentOS 5.9 x86_64 using http://www.monshouwer.eu/download/3rd_party/pdns-server/el5/SRPMS/pdns-server-3.2-1.el5.MIND.src.rpm and this worked fine with the standard CentOS OpenLDAP libs. However, building using: LIBS=-L/usr/local/openldap/lib64 %build %configure \ --sysconfdir=%{_sysconfdir}/powerdns \ --libdir=%{_libdir} \ --with-sqlite3 \ --with-socketdir=/var/run/pdns-server \ --with-modules= \ --with-dynmodules=pipe gmysql gpgsql gsqlite3 ldap %{__make} I am not sure it produces the required result: ... /bin/sh ../../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -module -avoid-version -lrt -o libldapbackend.la -rpath /usr/lib64 ldapbackend.lo powerldap.lo -lldap_r -lz ... I understand that the compiler probably still uses: /usr/lib64/ for ldap libs, although we instructed (?) it to use ldap libs from /usr/local/openldap/lib64. So, there remain two questions: 1. How to build properly with custom LDAP libs? 2. Why we can't build correctly under CentOS 6, but only under CentOS 5? Regards, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
LIBS=-L/usr/local/openldap/lib64 What makes you believe that anything would pay attention to $LIBS? Did you see this in the code or documentation somewhere? %build %configure \ --sysconfdir=%{_sysconfdir}/powerdns \ --libdir=%{_libdir} \ --with-sqlite3 \ --with-socketdir=/var/run/pdns-server \ --with-modules= \ --with-dynmodules=pipe gmysql gpgsql gsqlite3 ldap %{__make} I am not sure it produces the required result: ... /bin/sh ../../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -module -avoid-version -lrt -o libldapbackend.la -rpath /usr/lib64 ldapbackend.lo powerldap.lo -lldap_r -lz ... I understand that the compiler probably still uses: /usr/lib64/ for ldap libs, although we instructed (?) it to use ldap libs from /usr/local/openldap/lib64. So, there remain two questions: 1. How to build properly with custom LDAP libs? You need to pass --libdir=/usr/local/openldap/lib64 on the %configure line. By the way, the correct place to put 3rd party and unbundled applications, even on GNU/Linux and especially on CentOS is /opt, in your case /opt/openldap. Configuration should go in /etc/opt/openldap, and data in /var/opt/openldap. These are controlled by --prefix=/opt/openldap --sysconfdir=/etc/opt/openldap --datadir=/var/opt/openldap when OpenLDAP is being built. OpenLDAP's ./configure might have additional switches for this. Reference: http://www.pathname.com/fhs/pub/fhs-2.3.html ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
Hmm, actually now that I tried to build using even the standard CentOS 6 RPMs/libs/headers/, it still fails at the same point. So, am I doing something wrong? Please advise. What does config.log say regarding ldap? ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On Tue, Mar 19, 2013 at 05:28:28PM +0200, Nikolaos Milas wrote: CXXFLAGS=${CXXFLAGS} -I/usr/local/openldap/include LDFLAGS=${LDFLAGS} -L/usr/local/openldap/lib64 -lldap -llber Can you try LIBS=-L/usr/local/openldap/lib64 ./configure ... ? And can you double check a libldap.so lives there? Bert -- PowerDNS Website: http://www.powerdns.com/ Contact us by phone on +31-15-7850372 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] Building pdns RPMs using custom LDAP libraries/headers
On 19/3/2013 5:28 μμ, Nikolaos Milas wrote: Can you please guide me on how to adapt the spec file so as to build correctly using the custom ldap libraries / headers? Hmm, actually now that I tried to build using even the standard CentOS 6 RPMs/libs/headers/, it still fails at the same point. So, am I doing something wrong? Please advise. Thanks, Nick ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users