Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2011-10-25 at 18:01 +0100, Jonathan Ludlam wrote:
> For reference, here's what's executed when I build the xenctrl package in 
> latest xen-unstable:
> 
> ocamlc -g -I ../mmap -w F -warn-error F -c -o xenctrl.cmi xenctrl.mli
> ocamlc -g -I ../mmap -w F -warn-error F -c -o xenctrl.cmo xenctrl.ml
> ocamlc -g -I ../mmap -w F -warn-error F -a -o xenctrl.cma  -dllib 
> dllxenctrl_stubs.so -cclib -lxenctrl_stubs  xenctrl.cmo
> gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing 
> -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value 
> -Wdeclaration-after-statement -Wno-unused-but-set-variable  -D__XEN_TOOLS__ 
> -MMD -MF .xenctrl_stubs.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls 
> -mno-tls-direct-seg-refs -I/usr/lib/ocaml -fPIC -Werror -I../mmap 
> -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc 
> -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/include 
> -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc 
> -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/include -c 
> -o xenctrl_stubs.o xenctrl_stubs.c
> ar rcs libxenctrl_stubs.a  xenctrl_stubs.o && ocamlmklib -o `basename 
> libxenctrl_stubs.a .a | sed -e 's/^lib//'`  xenctrl_stubs.o
> ocamlopt -g -ccopt "  " -dtypes -I ../mmap -cc gcc -w F -warn-error F -c -o 
> xenctrl.cmx xenctrl.ml
> ocamlopt -g -ccopt "  " -dtypes -I ../mmap -cc gcc -w F -warn-error F -a -o 
> xenctrl.cmxa  -cclib -lxenctrl_stubs -cclib 
> /home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so
>  -cclib 
> /home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc/libxenguest.so
>   xenctrl.cmx
> 
> The -cclib arguments specify additional command-line arguments that 
> will be passed to gcc. When you're building a library (as we are here) 
> they are *not* used unless you link against the library that has been 
> produced.

Ah, I was under the impression that it was used at both library build
and link time. It just being the latter simplifies things...

Ian.

>  The reason that they are specified is that the ocaml compiler 
> will record the -cclib and -ccopt command line arguments in the library. 
> When you then link against that library later, it will behave as if those
>  arguments were passed on the command line. In this case, it records
>  the " -cclib 
> /home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so"
>  
> which is unhelpful. The correct thing to do is to record the eventual
>  locations of the libraries. However, there's a slight complication: these
>  libraries are used in the compilation of the oxenstored binary. In order 
> to prevent it attempting to link against whatever is currently installed 
> instead of what's in the tree (which was the original bug), the option 
> "-noautolink" can be passed to the ocaml compiler which causes it to 
> ignore the recorded -cclib and -ccopt parameters, and we can instead
>  pass '-cclib /path/to/.so/file'.
> 
> I shall work on a patch :-)
> 
> Jon
> 
> 
> 
> On 25 Oct 2011, at 17:11, Ian Jackson wrote:
> 
> > George Dunlap writes ("Re: [Xen-devel] RFC: Partially revert xen-unstable 
> > c/s 23071:a3466b005017"):
> >> Yes; it hard-codes the full path of the build tree library file.
> > 
> > That seems a strange thing for it to do.
> > 
> >> You're right, it's actually 23921 that caused the problem.  I just did
> >> "hg annotate" and found 23071.
> > 
> > Reverting this part of 23921 will just bring back the previous bug,
> > that the build system might pick up libraries in /usr (or somewhere
> > else on the default compile-time linker search path).
> > 
> > Is there a way to get the ocaml linker stage to print out the complete
> > link line it's using ?  If so it'll probably be possible to spot the
> > difference between the link lines used for the ocaml libraries and
> > those used elsewhere.  Then we might understand what to fix.
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel