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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel