2012/1/13 Gerd Stolpmann <info@gerd-stolpmann.de>
Am Freitag, den 13.01.2012, 12:59 +0100 schrieb Philippe Veber:
> Dear camlers,
>
> Debian and Ubuntu have not so recently switched to multiarch binaries
> (including libs, see http://wiki.debian.org/Multiarch/Implementation).
> This is an important change for ocaml C bindings since the libraries
> are now to be found in /usr/lib/<arch description> instead
> of /usr/lib. I was just bitten by this, when realizing that the ocaml
> configure script couldn't find libX11.so and wouldn't install
> graphics. A similar problem was handled by the people in charge of
> debian ocaml packages
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619344). Now my
> question is the following: will this evolution be a problem for
> GODI/odb packages (and more generally source distribution), and what
> is the advised fix for it?

Good question. For GODI it means that the automatic library search is
broken. You can set the library path in most cases manually, though. (So
far I overlook it, this is only a problem for the libs
in /usr/lib/<arch>/<pkg> but not for the ones in /usr/lib/<arch> because
the latter can be linked without -L switches.)
That's what I thought too, but I'm hurt even for libX11 which is in /usr/lib/<arch>:

pveber@gesundheit:/usr/lib$ locate libX11.so
/usr/lib/x86_64-linux-gnu/libX11.so
/usr/lib/x86_64-linux-gnu/libX11.so.6
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0

This is related to ocaml configure script, which wants to see the lib before trying to compile

for dir in \
    $x11_lib_dir          \
    $x11_try_lib_dir      \
                          \
    /usr/X11R6/lib64      \
    /usr/X11R6/lib        \
    /usr/lib/X11R6        \
    /usr/local/X11R6/lib  \
    /usr/local/lib/X11R6  \
    /opt/X11R6/lib        \
                          \
    /usr/X11/lib          \
    /usr/lib/X11          \
    /usr/local/X11/lib    \
    /usr/local/lib/X11    \
    /opt/X11/lib          \
<SNIP>                        
    ; \
do
  if test -f $dir/libX11.a || \
     test -f $dir/libX11.so || \
     test -f $dir/libX11.dll.a || \
     test -f $dir/libX11.dylib || \
     test -f $dir/libX11.sa; then

So basically it may be an issue in all cases ...
 

The question is how to generically work around this.
right.
 
GODI could provide
a variable $USR_LIB_ARCH for the architecture-specific path prefix
corresponding to /usr/lib/<arch>, which is set if "dpkg-architecture
-qDEB_HOST_MULTIARCH" returns something. All the conf packages would
need to be updated.
I've already noticed that godi's smart enough to suggest debian packages in the bootstrap phase, so yes, probably your (optional, OS-specific) approach is the way to go (although it might be some work). Also notice with the example of graphics that many packages will have to be modified in order to propagate the information. In this particular example, one would have to add a --x11lib on the configure command.

 
In the future we will have many errors because not
all package developers will test on multiarch-enabled systems.
Just curious: are there many others than debian/ubuntu?
 

Don't know what else needs to be done.
Thanks for your input on this.

ph.

 

Gerd

> Cheers,
>   Philippe.
>

--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------