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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Oct 25, 2011 at 6:01 PM, Jonathan Ludlam
<Jonathan.Ludlam@xxxxxxxxxxxxx> 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. 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, is there any update on this?  It would be nice not to have to
carry the partial reversion above in Frontier...

 -George

>
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel