[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.