George Dunlap
2011-Oct-18 13:53 UTC
[Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
When trying to make a XenServer branch with xen-server, I managed to get Xen to build, but when I tried to use some of the ocaml output, I got the following errors: gcc: /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so: No such file or directory gcc: /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenguest.so: No such file or directory It appears that somehow the change made in 23071:a3466b005017 ended up putting in a hard-link to the exact directory of the library in the resulting .ml files, which is only used when someone attempts to actually use those files. Since, of course, those exact directories are gone when the RPM build is over, this doesn''t work very well. :-) The attached patch reverts the parts of 23071 which pertains to tools/ocaml/libs/xc, and the resulting *.ml files work properly again. But I''m not sure what the desired approach is going forward -- I''m not familiar enough with the ocaml link process to know what a "proper" fix would be (i.e., one which accomplishes the goal of 23071) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Oct-18 14:11 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, 2011-10-18 at 14:53 +0100, George Dunlap wrote:> When trying to make a XenServer branch with xen-server, I managed to > get Xen to build, but when I tried to use some of the ocaml output, I > got the following errors: > > gcc: /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so: > No such file or directory > gcc: /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenguest.so: > No such file or directory > > > It appears that somehow the change made in 23071:a3466b005017 ended up > putting in a hard-link to the exact directory of the library in the > resulting .ml files, which is only used when someone attempts to > actually use those files.The use of "hard-link" here is confusing. You presumably mean it bakes the literal/precise path into the binary.> Since, of course, those exact directories > are gone when the RPM build is over, this doesn''t work very well. :-) > > The attached patch reverts the parts of 23071 which pertains to > tools/ocaml/libs/xc, and the resulting *.ml files work properly again. > But I''m not sure what the desired approach is going forward -- I''m > not familiar enough with the ocaml link process to know what a > "proper" fix would be (i.e., one which accomplishes the goal of 23071)> diff -r 4b0907c6a08c tools/ocaml/libs/xc/Makefile > --- a/tools/ocaml/libs/xc/Makefile Tue Oct 11 12:02:58 2011 +0100 > +++ b/tools/ocaml/libs/xc/Makefile Thu Oct 13 17:28:06 2011 +0100 > @@ -9,7 +9,7 @@ OBJS = xenctrl > INTF = xenctrl.cmi > LIBS = xenctrl.cma xenctrl.cmxa > > -LIBS_xenctrl = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)Nowadays this expands to: $(XEN_LIBXC)/libxenctrl.so $(XEN_LIBXC)/libxenguest.so prior to 23921:19d2922bcfb9 it would have been: -L$(XEN_LIBXC) -lxenctrl -L$(XEN_LIBXC) -lxenguest which tree were you working against? Are you sure 23071:a3466b005017 and not 23921:19d2922bcfb9 is to blame? The <23931 version doesn''t seem materially different to the <21071 one whereas I can plausibly imagine that 23931 might have made a difference. If this had been using $(SHLIB_foo) I could have imagined ways in which that might go wrong.> +LIBS_xenctrl = -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguestIan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Oct-18 14:15 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, 2011-10-18 at 15:11 +0100, Ian Campbell wrote:> On Tue, 2011-10-18 at 14:53 +0100, George Dunlap wrote: > > When trying to make a XenServer branch with xen-server, I managed to > > get Xen to build, but when I tried to use some of the ocaml output, I > > got the following errors: > > > > gcc: /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so: > > No such file or directory > > gcc: /bind/obj/RPM_BUILD_DIRECTORY/xen-4.2.unstable/tools/ocaml/libs/xc/../../../../tools/libxc/libxenguest.so: > > No such file or directory > > > > > > It appears that somehow the change made in 23071:a3466b005017 ended up > > putting in a hard-link to the exact directory of the library in the > > resulting .ml files, which is only used when someone attempts to > > actually use those files. > > The use of "hard-link" here is confusing. You presumably mean it bakes > the literal/precise path into the binary. > > > Since, of course, those exact directories > > are gone when the RPM build is over, this doesn''t work very well. :-) > > > > The attached patch reverts the parts of 23071 which pertains to > > tools/ocaml/libs/xc, and the resulting *.ml files work properly again. > > But I''m not sure what the desired approach is going forward -- I''m > > not familiar enough with the ocaml link process to know what a > > "proper" fix would be (i.e., one which accomplishes the goal of 23071) > > > diff -r 4b0907c6a08c tools/ocaml/libs/xc/Makefile > > --- a/tools/ocaml/libs/xc/Makefile Tue Oct 11 12:02:58 2011 +0100 > > +++ b/tools/ocaml/libs/xc/Makefile Thu Oct 13 17:28:06 2011 +0100 > > @@ -9,7 +9,7 @@ OBJS = xenctrl > > INTF = xenctrl.cmi > > LIBS = xenctrl.cma xenctrl.cmxa > > > > -LIBS_xenctrl = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) > > Nowadays this expands to: > $(XEN_LIBXC)/libxenctrl.so $(XEN_LIBXC)/libxenguest.so > prior to 23921:19d2922bcfb9 it would have been: > -L$(XEN_LIBXC) -lxenctrl -L$(XEN_LIBXC) -lxenguest > > which tree were you working against? > > Are you sure 23071:a3466b005017 and not 23921:19d2922bcfb9 is to blame? > The <23931 version doesn''t seem materially different to the <21071 one > whereas I can plausibly imagine that 23931 might have made a difference.The rules in tools/ocaml/Makefile.rules use: $(foreach lib,$(LIBS_$(1)),-cclib $(lib)) Where -cclib is documented as passing -l<arg> to the linker. Passing "-l $(XEN_LIBXC)/libxenctrl.so" doesn''t seem like it is going to be right. -ccopt just passes the raw argument in and seems likely to be more correct (irrespective of any of the changesets mentioned here, since the variable seems to have always included -L and -l itself). Perhaps that helps?> > If this had been using $(SHLIB_foo) I could have imagined ways in which > that might go wrong. > > > +LIBS_xenctrl = -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-Oct-18 14:32 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, Oct 18, 2011 at 3:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> The use of "hard-link" here is confusing. You presumably mean it bakes > the literal/precise path into the binary.Yes; it hard-codes the full path of the build tree library file.> Nowadays this expands to: > $(XEN_LIBXC)/libxenctrl.so $(XEN_LIBXC)/libxenguest.so > prior to 23921:19d2922bcfb9 it would have been: > -L$(XEN_LIBXC) -lxenctrl -L$(XEN_LIBXC) -lxenguest > > which tree were you working against?Not sure what you''re asking; this is XenServer trunk, with the xen.hg pulled in from xen-unstable (pulled recently, like Friday or something).> Are you sure 23071:a3466b005017 and not 23921:19d2922bcfb9 is to blame? > The <23931 version doesn''t seem materially different to the <21071 one > whereas I can plausibly imagine that 23931 might have made a difference.You''re right, it''s actually 23921 that caused the problem. I just did "hg annotate" and found 23071.> -ccopt just passes the raw argument in and seems likely to be more > correct (irrespective of any of the changesets mentioned here, since the > variable seems to have always included -L and -l itself). Perhaps that > helps?Sorry, I''m having trouble mentally compling this paragraph into patch. :-) (In part no doubt because I don''t understand the make syntax you mention.) Could you explain what you mean? Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Oct-18 14:45 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, 2011-10-18 at 15:32 +0100, George Dunlap wrote:> On Tue, Oct 18, 2011 at 3:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > The use of "hard-link" here is confusing. You presumably mean it bakes > > the literal/precise path into the binary. > > Yes; it hard-codes the full path of the build tree library file. > > > Nowadays this expands to: > > $(XEN_LIBXC)/libxenctrl.so $(XEN_LIBXC)/libxenguest.so > > prior to 23921:19d2922bcfb9 it would have been: > > -L$(XEN_LIBXC) -lxenctrl -L$(XEN_LIBXC) -lxenguest > > > > which tree were you working against? > > Not sure what you''re asking; this is XenServer trunk, with the xen.hg > pulled in from xen-unstable (pulled recently, like Friday or > something).I was asking which precise xen-unstable.hg you had pulled in.> > Are you sure 23071:a3466b005017 and not 23921:19d2922bcfb9 is to blame? > > The <23931 version doesn''t seem materially different to the <21071 one > > whereas I can plausibly imagine that 23931 might have made a difference. > > You''re right, it''s actually 23921 that caused the problem. I just did > "hg annotate" and found 23071.OK, that makes more sense, presumably ocaml just ends up embedding the raw arguments to -cc* in the binary.> > -ccopt just passes the raw argument in and seems likely to be more > > correct (irrespective of any of the changesets mentioned here, since the > > variable seems to have always included -L and -l itself). Perhaps that > > helps? > > Sorry, I''m having trouble mentally compling this paragraph into patch. > :-) (In part no doubt because I don''t understand the make syntax you > mention.) Could you explain what you mean?The man page for ocamlopt says: -cclib -llibname Pass the -llibname option to the linker. This causes the given C library to be linked with the program. -ccopt option Pass the given option to the C compiler and linker. For instance, -ccopt -Ldir causes the C linker to search for C libraries in directory dir. Which I misread to think that -cclib _added_ the "-l" to its argument but actually it just passes the argument through, so I think this is a red-herring. In case you were wondering I was effectively proposing the following patch, but I now think that suggestion was wrong. diff -r e6af32ecb448 tools/ocaml/Makefile.rules --- a/tools/ocaml/Makefile.rules Tue Oct 18 14:15:09 2011 +0100 +++ b/tools/ocaml/Makefile.rules Tue Oct 18 15:37:18 2011 +0100 @@ -59,7 +59,7 @@ mk-caml-lib-stubs = \ # define a library target <name>.cmxa and <name>.cma define OCAML_LIBRARY_template $(1).cmxa: lib$(1)_stubs.a $(foreach obj,$($(1)_OBJS),$(obj).cmx) - $(call mk-caml-lib-native,$$@, -cclib -l$(1)_stubs $(foreach lib,$(LIBS_$(1)),-cclib $(lib)), $(foreach obj,$($(1)_OBJS),$(obj).cmx)) + $(call mk-caml-lib-native,$$@, -cclib -l$(1)_stubs $(foreach lib,$(LIBS_$(1)),-ccopt $(lib)), $(foreach obj,$($(1)_OBJS),$(obj).cmx)) $(1).cma: $(foreach obj,$($(1)_OBJS),$(obj).cmo) $(call mk-caml-lib-bytecode,$$@, -dllib dll$(1)_stubs.so -cclib -l$(1)_stubs, $$+) $(1)_stubs.a: $(foreach obj,$$($(1)_C_OBJS),$(obj).o)> > Thanks, > -George_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-Oct-25 16:11 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
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@lists.xensource.com
http://lists.xensource.com/xen-devel
Jonathan Ludlam
2011-Oct-25 16:25 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
It''s possible to print out the invocation of gcc by appending a -v on the end of the ocamlmklib command line. What would it be best to compare the gcc flags with? 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@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Oct-25 16:31 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, 2011-10-25 at 17:11 +0100, 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.AIUI when you link an ocaml library it actually bakes in the literal options which you gave into the result, in order that it can use them again when you subsequently link an application against that library. i.e. if you link with -lfoo then a literal "-lfoo" is stored in the library and reused by the ocaml linker when it invokes gcc to link the final application Likewise if you use e.g. "/home/ianc/devel/xen/tools/ocaml/libs/xc/../../../libxc/libxenctrl.so" then that will also be baked verbatim into the ocaml library. I don''t see how this can ever be made to work without changing the ocaml linker, you very much need to specify libraries differently when linking users which are in tree vs. out of tree and short of teaching ocaml about that distinction I don''t know what we can do. I suppose we could create two versions of the library (in and out) but that''s horrible. But then so is the whole scheme, iff I understand correctly and it really is as I describe. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jonathan Ludlam
2011-Oct-25 17:01 UTC
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@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Oct-25 18:00 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
At 17:31 +0100 on 25 Oct (1319563891), Ian Campbell wrote:> AIUI when you link an ocaml library it actually bakes in the literal > options which you gave into the result, in order that it can use them > again when you subsequently link an application against that library. > i.e. if you link with -lfoo then a literal "-lfoo" is stored in the > library and reused by the ocaml linker when it invokes gcc to link the > final application > > Likewise if you use e.g. > "/home/ianc/devel/xen/tools/ocaml/libs/xc/../../../libxc/libxenctrl.so" > then that will also be baked verbatim into the ocaml library.That would be pretty unfriendly of it. Could the problem be solved by just making sure the in-tree library paths are before any system ones? Actually, it seems like the original problem could be solved that way, so I must be missing some wrinkle of it.> I don''t see how this can ever be made to work without changing the ocaml > linker, you very much need to specify libraries differently when linking > users which are in tree vs. out of tree and short of teaching ocaml > about that distinction I don''t know what we can do.sed? :) Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Oct-25 20:51 UTC
Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017
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@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2012-Mar-02 12:20 UTC
Re: RFC: Partially revert xen-unstable c/s 23071:a3466b005017
On Tue, Oct 25, 2011 at 6:01 PM, Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com> 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@lists.xensource.com > http://lists.xensource.com/xen-devel