Bug 789819 - cross-compilation impossible due to ucommon-config misconfiguration
Summary: cross-compilation impossible due to ucommon-config misconfiguration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ucommon
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Sugar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-13 03:20 UTC by Mr-4
Modified: 2012-04-12 03:12 UTC (History)
1 user (show)

Fixed In Version: ucommon-5.2.2-1.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-31 13:07:01 UTC
Type: ---


Attachments (Terms of Use)

Description Mr-4 2012-02-13 03:20:21 UTC
Description of problem:
As it stands, I cannot have -devel packages installed for both i686 and x86_64 arches because in ucommon-config the value of the system lib location is  hard-coded to be /usr/lib{64}, which gets overwritten by whatever arch-specific version I install on my system.

This is making cross-compilation of *any* packages depending on ucommon-devel impossible.

Version-Release number of selected component (if applicable):
Any version (checked 2.0.7 to the latest at rawhide - 5.0.4)

How reproducible:
Always

Steps to Reproduce:
1. look at /usr/bin/ ucommon-config
2.
3.
  
Actual results:
/usr/bin/ccgnu2-config (i686) has -L/usr/lib (line 107 or thereabouts)
/usr/bin/ccgnu2-config (x86_64) has -L/usr/lib64

both are hard-coded.

Expected results:
The above should not be made to be hard-coded, but dependent on the various flags passed by autoconf/automake to determine the proper architecture used for compilation/build, or, alternatively, use the work-around below.

Additional info:

A possible work-around to determine the proper lib/lib64 name would be by using a similar set of statements as currently present at the top of that file:

if [ "`ldd /bin/sh | grep lib64`" = "" ]
then
    libdir=${exec_prefix}/lib
else
    libdir=${exec_prefix}/lib64
fi

Comment 1 Mr-4 2012-02-13 03:22:37 UTC
(In reply to comment #0)
> Actual results:
> /usr/bin/ccgnu2-config (i686) has -L/usr/lib (line 107 or thereabouts)
> /usr/bin/ccgnu2-config (x86_64) has -L/usr/lib64
That should be "/usr/bin/ucommon-config", obviously!

Comment 2 David Sugar 2012-02-13 09:17:49 UTC
They are not hardcoded, but parsed from "ucommon-config.in" by substituting from automake/autoconf:

"ucommon-config.in(107)"
    echo -lusecure -lucommon @SECURE_LIBS@ @UCOMMON_LINKED@ 

But this happens at build-time rather than at runtime.

Comment 3 Mr-4 2012-02-13 14:28:42 UTC
Whatever method is used, it "assumes" that no cross-compilation takes place (build=host=target) and uses the "build" arch in order to set libdir, which is wrong - setting up libdir should depend on the "host" arch selected at build time.

One other thing - I haven't tried excluding libdir entirely, but isn't specifying libdir unnecessary - most modern-day autoconf/automake tools determine the [/usr]/lib[64] value anyway as it is the system path where all libraries reside, so I am not sure including libdir in /usr/bin/ucommon-config is really necessary.

Lastly, what I posted as a "solution" in the "additional info" section does not work - I guess I was being a little over-enthusiastic when I typed it.

Comment 4 David Sugar 2012-02-14 10:11:02 UTC
It actually uses "${libdir}" as passed/processed in configure.ac:

configure.ac(580):

AC_SUBST_DIR(includes, includedir)
AC_SUBST_DIR(libs, libdir)

if test "$libs" != "/usr/lib" ; then
    UCOMMON_LINKED="-L$libs $UCOMMON_LINKED" ; fi

if test "$includes" != "/usr/include" ; then
    UCOMMON_FLAGS="$UCOMMON_FLAGS -I$includes" ; fi

And then only for non-default paths.  However, you are correct, it also does try to compute a library path in ucommon-config itself as well...!  This actually contradicts the .pc file...

However, in all cases:

[dyfet@tycho ucommon]$ bash ./ucommon-config --libs
-lusecure -lucommon -lssl -lcrypto -L/usr/local/lib -lnsl -lrt -ldl -lpthread
[dyfet@tycho ucommon]$ linux32 bash ./ucommon-config --libs
-lusecure -lucommon -lssl -lcrypto -L/usr/local/lib -lnsl -lrt -ldl -lpthread

This does match what is in configure "libdir", and what is in the .pc file.  If the prefix or libdir is coerced in configure as part of a cross-compile, it should work.  Hence...:

./configure --prefix=/tmp/cross-test
[dyfet@tycho ucommon]$ bash ./ucommon-config --libs
-lusecure -lucommon -lgnutls -lgcrypt -L/tmp/cross-test/lib -lnsl -lrt -ldl -lpthread
[dyfet@tycho ucommon]$ linux32 bash ./ucommon-config --libs
-lusecure -lucommon -lgnutls -lgcrypt -L/tmp/cross-test/lib -lnsl -lrt -ldl -lpthread

This seems correct...

as does:

[dyfet@tycho ucommon]$ ./configure --libdir=/tmp/cross-prefix/libs/armel
[dyfet@tycho ucommon]$ bash ./ucommon-config --libs
-lusecure -lucommon -lgnutls -lgcrypt -L/tmp/cross-prefix/libs/armel -lnsl -lrt -ldl -lpthread

The only odd one is --libtool-libs...

Comment 5 Mr-4 2012-02-14 14:00:29 UTC
(In reply to comment #4)
> However, in all cases:
> 
> [dyfet@tycho ucommon]$ bash ./ucommon-config --libs
> -lusecure -lucommon -lssl -lcrypto -L/usr/local/lib -lnsl -lrt -ldl -lpthread
> [dyfet@tycho ucommon]$ linux32 bash ./ucommon-config --libs
> -lusecure -lucommon -lssl -lcrypto -L/usr/local/lib -lnsl -lrt -ldl -lpthread
> 
> This does match what is in configure "libdir", and what is in the .pc file.  
Nope! For 64-bit arches (at least in my case) libdir is /usr/lib64, not /usr/lib!
For 32bit this is /usr/lib.

> If the prefix or libdir is coerced in configure as part of a cross-compile, it
> should work.  Hence...:
> 
> ./configure --prefix=/tmp/cross-test
> [dyfet@tycho ucommon]$ bash ./ucommon-config --libs
> -lusecure -lucommon -lgnutls -lgcrypt -L/tmp/cross-test/lib -lnsl -lrt -ldl
> -lpthread
> [dyfet@tycho ucommon]$ linux32 bash ./ucommon-config --libs
> -lusecure -lucommon -lgnutls -lgcrypt -L/tmp/cross-test/lib -lnsl -lrt -ldl
> -lpthread
> 
> This seems correct...
Again, the libdir for 64bit arches is /usr/lib64, not /usr/lib or ${prefix}/lib

> 
> as does:
> 
> [dyfet@tycho ucommon]$ ./configure --libdir=/tmp/cross-prefix/libs/armel
> [dyfet@tycho ucommon]$ bash ./ucommon-config --libs
> -lusecure -lucommon -lgnutls -lgcrypt -L/tmp/cross-prefix/libs/armel -lnsl -lrt
> -ldl -lpthread
So, if I specify --libdir at configure time would that work (i.e. --libdir=/usr/lib64 for x86_64 and --libdir=/usr/lib for i686)? 

If so, that's a good workaround though I do not agree with having libdir paths hard-coded in ucommon-config - it is plainly wrong! 

Besides, it screws up rpm when I try to install both packages on the same system - RPM tells me there is ucommon-config conflict (and it is right, because libdir is hard-coded differently for different arches used).

Comment 6 David Sugar 2012-03-31 13:07:01 UTC
This is being handled upstream for 5.2.2 and later.

Comment 7 Fedora Update System 2012-03-31 15:36:46 UTC
ucommon-5.2.2-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/ucommon-5.2.2-1.fc17

Comment 8 Fedora Update System 2012-04-12 03:12:19 UTC
ucommon-5.2.2-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.