[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |