Patchwork netatalk : Fix BerkeleyDB library path

login
register
mail settings
Submitter Maxime Hadjinlian
Date Dec. 8, 2012, 3:53 p.m.
Message ID <1354981988-32415-1-git-send-email-maxime.hadjinlian@gmail.com>
Download mbox | patch
Permalink /patch/204673/
State Accepted
Headers show

Comments

Maxime Hadjinlian - Dec. 8, 2012, 3:53 p.m.
This fix is needed for the 64bits build because Netatalk will assume the library
are stored in [..]/lib64/ instead of [..]/lib/

Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
---
 package/netatalk/netatalk.mk |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--
1.7.10.4
Peter Korsgaard - Dec. 16, 2012, 10:54 a.m.
>>>>> "Maxime" == Maxime Hadjinlian <maxime.hadjinlian@gmail.com> writes:

 Maxime> This fix is needed for the 64bits build because Netatalk will assume the library
 Maxime> are stored in [..]/lib64/ instead of [..]/lib/

Committed, thanks.
Peter Korsgaard - Dec. 16, 2012, 10:17 p.m.
>>>>> "Maxime" == Maxime Hadjinlian <maxime.hadjinlian@gmail.com> writes:

 Maxime> This fix is needed for the 64bits build because Netatalk will assume the library
 Maxime> are stored in [..]/lib64/ instead of [..]/lib/

Hmm, we still seem to have issues on the autobuilders:

http://autobuild.buildroot.net/results/cf5c3ce94c229204bfa0f19b1009c13a9bcc1dfc/build-end.log

 Maxime> +++ b/package/netatalk/netatalk.mk
 Maxime> @@ -8,7 +8,7 @@ NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NET
 Maxime>  NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2

 Maxime>  NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
 Maxime> -NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
 Maxime> +NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_LIB)/usr/lib


I guess you meant STAGING_DIR instead here, will fix.
Maxime Hadjinlian - Dec. 16, 2012, 11:15 p.m.
On Sun, Dec 16, 2012 at 11:17 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Maxime" == Maxime Hadjinlian <maxime.hadjinlian@gmail.com> writes:
>
>  Maxime> This fix is needed for the 64bits build because Netatalk will assume the library
>  Maxime> are stored in [..]/lib64/ instead of [..]/lib/
>
> Hmm, we still seem to have issues on the autobuilders:
>
> http://autobuild.buildroot.net/results/cf5c3ce94c229204bfa0f19b1009c13a9bcc1dfc/build-end.log
>
>  Maxime> +++ b/package/netatalk/netatalk.mk
>  Maxime> @@ -8,7 +8,7 @@ NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NET
>  Maxime>  NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
>
>  Maxime>  NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
>  Maxime> -NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
>  Maxime> +NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_LIB)/usr/lib
>
>
> I guess you meant STAGING_DIR instead here, will fix.
This is strange because I tested with a 64 bits build and I had'nt the
problem anymore.. And I don't remember rewriting the patch before
sending it here. But then again, you're totally right, this does'nt
make sense. I'm really wondering how it could have worked for me :/
>
> --
> Bye, Peter Korsgaard
Arnout Vandecappelle - Dec. 17, 2012, 8:35 p.m.
On 17/12/12 00:15, Maxime Hadjinlian wrote:
> On Sun, Dec 16, 2012 at 11:17 PM, Peter Korsgaard<jacmet@uclibc.org>  wrote:
>>>>>>> "Maxime" == Maxime Hadjinlian<maxime.hadjinlian@gmail.com>  writes:
>>
>>   Maxime>  This fix is needed for the 64bits build because Netatalk will assume the library
>>   Maxime>  are stored in [..]/lib64/ instead of [..]/lib/
>>
>> Hmm, we still seem to have issues on the autobuilders:
>>
>> http://autobuild.buildroot.net/results/cf5c3ce94c229204bfa0f19b1009c13a9bcc1dfc/build-end.log
>>
>>   Maxime>  +++ b/package/netatalk/netatalk.mk
>>   Maxime>  @@ -8,7 +8,7 @@ NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NET
>>   Maxime>   NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
>>
>>   Maxime>   NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
>>   Maxime>  -NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
>>   Maxime>  +NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_LIB)/usr/lib
>>
>>
>> I guess you meant STAGING_DIR instead here, will fix.
> This is strange because I tested with a 64 bits build and I had'nt the
> problem anymore.. And I don't remember rewriting the patch before
> sending it here. But then again, you're totally right, this does'nt
> make sense. I'm really wondering how it could have worked for me :/

 I guess it was an accident then :-)

 configure checks for libdb by doing: ls $bdblibdir/lib$lib.*
and bdblibdir="${bdbdir}/${atalk_libname}" and atalk_libname="lib64" for 
most 64-bit architectures.

 So you happened to have an existing /usr/lib/lib64/libdb* on your build 
machine...

 BDB_LIB isn't even used by configure, so I don't think does patch does 
much :-)


 The problem I encounter in my build is that configure uses `ls ...` to 
find the library, and my /bin/ls is linked against libacl.so.1. It seems 
LD_LIBRARY_PATH is overridden because ls fails with:

/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libacl.so.1

 And indeed, configure sets:
eval export $shlibpath_var=$bdblibdir

 This is OK for native builds, but not for cross-builds...

 Looking a bit further into macros/db3-check.m4, it looks even worse:
after that configure step, there is an
eval export $shlibpath_var=$saved_shlibpath_var
which expands to
export LD_LIBRARY_PATH=LD_LIBRARY_PATH
:-)

 I'll try to cook a fix and send a patch.

 Regards,
 Arnout
Maxime Hadjinlian - Dec. 17, 2012, 10 p.m.
On Mon, Dec 17, 2012 at 9:35 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 17/12/12 00:15, Maxime Hadjinlian wrote:
>> On Sun, Dec 16, 2012 at 11:17 PM, Peter Korsgaard<jacmet@uclibc.org>  wrote:
>>>>>>>> "Maxime" == Maxime Hadjinlian<maxime.hadjinlian@gmail.com>  writes:
>>>
>>>   Maxime>  This fix is needed for the 64bits build because Netatalk will assume the library
>>>   Maxime>  are stored in [..]/lib64/ instead of [..]/lib/
>>>
>>> Hmm, we still seem to have issues on the autobuilders:
>>>
>>> http://autobuild.buildroot.net/results/cf5c3ce94c229204bfa0f19b1009c13a9bcc1dfc/build-end.log
>>>
>>>   Maxime>  +++ b/package/netatalk/netatalk.mk
>>>   Maxime>  @@ -8,7 +8,7 @@ NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NET
>>>   Maxime>   NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2
>>>
>>>   Maxime>   NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
>>>   Maxime>  -NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
>>>   Maxime>  +NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_LIB)/usr/lib
>>>
>>>
>>> I guess you meant STAGING_DIR instead here, will fix.
>> This is strange because I tested with a 64 bits build and I had'nt the
>> problem anymore.. And I don't remember rewriting the patch before
>> sending it here. But then again, you're totally right, this does'nt
>> make sense. I'm really wondering how it could have worked for me :/
>
>  I guess it was an accident then :-)
>
>  configure checks for libdb by doing: ls $bdblibdir/lib$lib.*
> and bdblibdir="${bdbdir}/${atalk_libname}" and atalk_libname="lib64" for
> most 64-bit architectures.
>
>  So you happened to have an existing /usr/lib/lib64/libdb* on your build
> machine...
I looked for it but I don't have one, I have although my host system
is 64bits, there should some bits in there...
>
>  BDB_LIB isn't even used by configure, so I don't think does patch does
> much :-)
You're right, it should be BDB_LIBS at least.
>
>
>  The problem I encounter in my build is that configure uses `ls ...` to
> find the library, and my /bin/ls is linked against libacl.so.1. It seems
> LD_LIBRARY_PATH is overridden because ls fails with:
>
> /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libacl.so.1
>
>  And indeed, configure sets:
> eval export $shlibpath_var=$bdblibdir
>
>  This is OK for native builds, but not for cross-builds...
If I'm reading this correctly (and I'm not sure I am), there is one
bug with ls if you native hosts is 32bits but also, if you look the
value of atalk_libname, it will value lib64 and since the lib are not
put there by BerkeleyDB, it will also fail. And so we must look for
them in lib, right ? (That was I tried to fixed in my numerous
attempt).
So is it possible that there is two bugs enclosed here ?
>
>  Looking a bit further into macros/db3-check.m4, it looks even worse:
> after that configure step, there is an
> eval export $shlibpath_var=$saved_shlibpath_var
> which expands to
> export LD_LIBRARY_PATH=LD_LIBRARY_PATH
> :-)
Which is obviously not what we want here :).
>
>  I'll try to cook a fix and send a patch.
I'm really curious to see something, because I don't think I could
have figured this one out myself (given the lack of experience in
cross compiling and also my host being 64bits, well I'm short on
excuses).
>
>  Regards,
>  Arnout
Thanks !
>
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Arnout Vandecappelle - Dec. 17, 2012, 10:05 p.m.
On 17/12/12 23:00, Maxime Hadjinlian wrote:
> On Mon, Dec 17, 2012 at 9:35 PM, Arnout Vandecappelle<arnout@mind.be>  wrote:
>> On 17/12/12 00:15, Maxime Hadjinlian wrote:
[snip]
>>   BDB_LIB isn't even used by configure, so I don't think does patch does
>> much :-)
> You're right, it should be BDB_LIBS at least.

  But BDB_LIBS is unconditionally set by configure.


>>   The problem I encounter in my build is that configure uses `ls ...` to
>> find the library, and my /bin/ls is linked against libacl.so.1. It seems
>> LD_LIBRARY_PATH is overridden because ls fails with:
>>
>> /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libacl.so.1
>>
>>   And indeed, configure sets:
>> eval export $shlibpath_var=$bdblibdir
>>
>>   This is OK for native builds, but not for cross-builds...
> If I'm reading this correctly (and I'm not sure I am), there is one
> bug with ls if you native hosts is 32bits but also, if you look the
> value of atalk_libname, it will value lib64 and since the lib are not
> put there by BerkeleyDB, it will also fail. And so we must look for
> them in lib, right ? (That was I tried to fixed in my numerous
> attempt).

  Yes, but the configure script already does that: if it fails to find it 
in $atalk_libname and $atalk_libname != lib then it tries again in lib.

  Regards,
  Arnout

[snip]
Maxime Hadjinlian - Dec. 17, 2012, 10:13 p.m.
On Mon, Dec 17, 2012 at 11:05 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 17/12/12 23:00, Maxime Hadjinlian wrote:
>>
>> On Mon, Dec 17, 2012 at 9:35 PM, Arnout Vandecappelle<arnout@mind.be>
>> wrote:
>>>
>>> On 17/12/12 00:15, Maxime Hadjinlian wrote:
>
> [snip]
>
>>>   BDB_LIB isn't even used by configure, so I don't think does patch does
>>> much :-)
>>
>> You're right, it should be BDB_LIBS at least.
>
>
>  But BDB_LIBS is unconditionally set by configure.
>
>
>
>>>   The problem I encounter in my build is that configure uses `ls ...` to
>>> find the library, and my /bin/ls is linked against libacl.so.1. It seems
>>> LD_LIBRARY_PATH is overridden because ls fails with:
>>>
>>> /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required
>>> by
>>> /home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libacl.so.1
>>>
>>>   And indeed, configure sets:
>>> eval export $shlibpath_var=$bdblibdir
>>>
>>>   This is OK for native builds, but not for cross-builds...
>>
>> If I'm reading this correctly (and I'm not sure I am), there is one
>> bug with ls if you native hosts is 32bits but also, if you look the
>> value of atalk_libname, it will value lib64 and since the lib are not
>> put there by BerkeleyDB, it will also fail. And so we must look for
>> them in lib, right ? (That was I tried to fixed in my numerous
>> attempt).
>
>
>  Yes, but the configure script already does that: if it fails to find it in
> $atalk_libname and $atalk_libname != lib then it tries again in lib.
Okay, I see what I missed and I'm looking at your patch, I'll go to
bed less stupid.
>
>  Regards,
>  Arnout
Thanks
>
> [snip]
>
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Arnout Vandecappelle - Dec. 17, 2012, 10:18 p.m.
On 17/12/12 23:13, Maxime Hadjinlian wrote:
> On Mon, Dec 17, 2012 at 11:05 PM, Arnout Vandecappelle<arnout@mind.be>  wrote:
[snip]
>>   Yes, but the configure script already does that: if it fails to find it in
>> $atalk_libname and $atalk_libname != lib then it tries again in lib.
> Okay, I see what I missed and I'm looking at your patch, I'll go to
> bed less stupid.

  The only reason I'm less stupid is that I spent three hours looking at 
that configure script...

  Regards,
  Arnout

Patch

diff --git a/package/netatalk/netatalk.mk b/package/netatalk/netatalk.mk
index 4063b53..23c2a95 100644
--- a/package/netatalk/netatalk.mk
+++ b/package/netatalk/netatalk.mk
@@ -8,7 +8,7 @@  NETATALK_SITE = http://downloads.sourceforge.net/project/netatalk/netatalk/$(NET
 NETATALK_SOURCE = netatalk-$(NETATALK_VERSION).tar.bz2

 NETATALK_DEPENDENCIES = host-pkgconf openssl berkeleydb libgcrypt libgpg-error
-NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99"
+NETATALK_CONF_ENV += CC="$(TARGET_CC) -std=gnu99" BDB_LIB=$(STAGING_LIB)/usr/lib
 NETATALK_CONF_OPT += --with-cnid-cdb-backend \
 	--with-bdb=$(STAGING_DIR)/usr \
 	--disable-zeroconf \