Re: Fwd: Re: gtkpod toolchain

On 23/05/11 03:45, Michael Biebl wrote:
> Am 23.05.2011 04:34, schrieb Michael Biebl:
>>
>> The rpath issue is explained in detail at [1].
>> See especially "rpath issue on amd64".
> 
> 
> I've taken a look at the aclocal.m4 file that is shipped in the gtkpod 2.0.1
> upstream tarball, see line 3131 and following:
> 
> ================================================================
>   sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff}"
> 
>   # Append ld.so.conf contents to the search path
>   if test -f /etc/ld.so.conf; then
>     lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s
> 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' <
> /etc/ld.so.conf | $SED -e 's/#.*//;/^[↦  ]*hwcap[↦       ]/d;s/[:,↦     ]/
> /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
>     sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec $lt_ld_extra"
>   fi
> ================================================================
> 
> It is exactly the problem [2]  is talking, ie. a ${libsuff} is appended to the
> library search path, as a result the linker is told to look for libraries in
> /usr/lib64, but on debian the libraries are in /usr/lib.
> As a consequence, an rpath is encoded.
> 
> If I regenerate the build system on my Debian system (use autoreconf -vfi), the
> relevant section in aclocal.m4 looks like
> 
> ================================================================
>   # Append ld.so.conf contents to the search path
>   if test -f /etc/ld.so.conf; then
>     lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s
> 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' <
> /etc/ld.so.conf | $SED -e 's/#.*//;/^[↦  ]*hwcap[↦       ]/d;s/[:,↦     ]/
> /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
>     sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
>   fi
> ================================================================
> 
> I hope this explains the issue in sufficient detail.
> 
> To fix this issue, you should update libtool, and regenerate the build system
> before the next release.
> You might double check by grepping for ld.so.conf in aclocal.m4, if the search
> path is correctly set.
> 
> Cheers,
> Michael
> 
> 
> [1] http://lists.debian.org/debian-devel/2008/01/msg00308.html
> 

Hi Michael,

Thanks for this. I can understand what is going and I think the issue
could be nothing more than me changing build server for the release.

As I mentioned, I have 4 build servers. Taking each one in turn:

Mandriva:
libtool: 2.2.6b
sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff}"

Fedora 14:
libtool: 2.2.10
sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib"

Fedora 15:
libtool: 2.4.4
sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib"
Comment: Currently producing the gtk3/anjuta3 version of gtkpod

Ubuntu Natty:
libtool: 2.2.6b
sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
Comment: Most closely aligned to debian requirements.

Clearly, Mandriva has the issue, already noted, although I find it a
little strange that it has the same version of libtool and Natty.
Although, I imagine the latter has been patched??

If I understand the Debian wiki (http://wiki.debian.org/RpathIssue)
correctly, both of the Fedoras should avoid the problem for Debian?

Would the use of Natty cause rpath issues for those using Fedora?


Therefore, is using Fedora as the build server the most appropriate
solution? Let me know what you think.

Regards

PGR


-- 
"I know exactly who reads the papers ...

The Daily Mirror is read by people who think they run the country.

The Guardian is read by people who think they ought to run the country.

The Times is read by people who do actually run the country.

The Daily Mail is read by the wives of the people who run the country.

The Financial Times is read by the people who own the country.

The Morning Star is read by the people who think the country ought to be
run by another country.

The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister


------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gtkpod-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel