compiling error "xen-unstable.hg"

compiling error "xen-unstable.hg"

[hackroute]

when i compiling xen-unstable.hg from
'http://xenbits.xen.org/hg/xen-unstable.hg' or staging reps
i have an error 

sed: -e expression #6, symbol 111:command not finished `s' 
make[2]: *** [include/xen/compile.h] error 1  

/xen-unstable.hg/xen/makefile:
...
# compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
include/xen/compile.h: include/xen/compile.h.in .banner
	@sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
...
	    -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) -v 2>&1 | grep version |
tail -1)!g' \
...
	    -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date}
{rev}:{node|short}" >/dev/null && hg parents --template "{date|date}
{rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
	    < include/xen/compile.h.in > $@.new
...

i remove " | grep version"
and it fixed this error


but now i have this error: 

make world:
...
ln -sf libxenlight.so.2.0.0 libxenlight.so.2.0
ln -sf libxenlight.so.2.0 libxenlight.so
gcc     -pthread -o xl xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o libxlutil.so
/home/alex/xen-unstable.hg/tools/libxl/../../tools/libxl/libxenlight.so
-Wl,-rpath-link=/home/alex/xen-unstable.hg/tools/libxl/../../tools/libxc
-Wl,-rpath-link=/home/alex/xen-unstable.hg/tools/libxl/../../tools/xenstore
-Wl,-rpath-link=/home/alex/xen-unstable.hg/tools/libxl/../../tools/blktap2/control
/home/alex/xen-unstable.hg/tools/libxl/../../tools/libxc/libxenctrl.so
-lyajl 
/home/alex/xen-unstable.hg/tools/libxl/../../tools/libxl/libxenlight.so:
undefined reference to `yajl_complete_parse'
collect2: execution  ld  finished with error code 1
make[4]: *** [xl]        error 1
make[4]: Выход из каталога `/home/alex/xen-unstable.hg/tools/libxl'
make[3]: *** [subdir-install-libxl]        (error 2)
make[3]: Выход из каталога `/home/alex/xen-unstable.hg/tools'
make[2]: *** [subdirs-install]         (error 2)
make[2]: Выход из каталога `/home/alex/xen-unstable.hg/tools'
make[1]: *** [install-tools]         (error 2)
make[1]: Выход из каталога `/home/alex/xen-unstable.hg'
make: *** [world]         (error 2)


libxl_json.c:
    status = yajl_complete_parse(yajl_ctx.hand);
    if (status != yajl_status_ok)
        goto out;

libxl_json.h:
 #define yajl_complete_parse yajl_parse_complete


how can i fix this error?

ubuntu 12.04 desktop  
with kernel 3.3.0-rc7-xen-teo.en.ming-sgp 
with kernel 3.2.0-27-generic



--
View this message in context: http://xen.1045712.n5.nabble.com/compiling-error-xen-unstable-hg-tp5710388.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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

Re: compiling error "xen-unstable.hg"

[Jan Beulich]

>>> On 27.07.12 at 09:24, hackroute <hackroute@mail.ru> wrote:
> when i compiling xen-unstable.hg from
> 'http://xenbits.xen.org/hg/xen-unstable.hg' or staging reps
> i have an error 
> 
> sed: -e expression #6, symbol 111:command not finished `s' 
> make[2]: *** [include/xen/compile.h] error 1  
> 
> /xen-unstable.hg/xen/makefile:
> ...
> # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> include/xen/compile.h: include/xen/compile.h.in .banner
> 	@sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> ...
> 	    -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) -v 2>&1 | grep version |
> tail -1)!g' \
> ...
> 	    -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date}
> {rev}:{node|short}" >/dev/null && hg parents --template "{date|date}
> {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> 	    < include/xen/compile.h.in > $@.new
> ...
> 
> i remove " | grep version"
> and it fixed this error

But that's certainly not the right fix. What output does
"$(CC) $(CFLAGS) -v" produce for you? In particular, does it
perhaps include any single quote character(s)?

> but now i have this error: 
>...
> /home/alex/xen-unstable.hg/tools/libxl/../../tools/libxl/libxenlight.so:
> undefined reference to `yajl_complete_parse'

Unsupported/wrong libyajl version (I don't recall whether support
for v2 of the library was ever added).

Jan

Re: compiling error "xen-unstable.hg"

[Ian Campbell]

On Fri, 2012-07-27 at 08:56 +0100, Jan Beulich wrote:
> > but now i have this error: 
> >...
> > /home/alex/xen-unstable.hg/tools/libxl/../../tools/libxl/libxenlight.so:
> > undefined reference to `yajl_complete_parse'
> 
> Unsupported/wrong libyajl version (I don't recall whether support
> for v2 of the library was ever added).

It was.

configure has a check for yajl/yajl_version.h and
tools/libxl/libxl_json.h uses this to determine v1 vs v2 (and assumes v1
if it is not present).

What does "grep YAJL tools/config.h" say?

Ian.

Re: compiling error "xen-unstable.hg"

[Ian Campbell]

Please keep the list on the CC line so that everyone can benefit. I've
put it back for you this time.

On Fri, 2012-07-27 at 10:16 +0100, Yuriy Logvinov wrote:
> > > but now i have this error: 
> > >...
> >
> > /home/alex/xen-unstable.hg/tools/libxl/../../tools/libxl/libxenlight.so:
> > > undefined reference to `yajl_complete_parse'
> > 
> > Unsupported/wrong libyajl version (I don't recall whether support
> > for v2 of the library was ever added).
> 
> It was.
> 
> configure has a check for yajl/yajl_version.h and
> tools/libxl/libxl_json.h uses this to determine v1 vs v2 (and assumes
> v1
> if it is not present).
> 
> What does "grep YAJL tools/config.h" say?
> 
>  Ian.

Please can you configure you MUA to give some indication of what is
quoted material and what you have added yourself.

> grep YAJL tools/config.h:
> 
> 
> #define HAVE_LIBYAJL 1
> #define HAVE_YAJL_YAJL_VERSION_H 1

What does /usr/incude/yajl/yajl_version.h contain?

What does "objdump -T /usr/lib/libyajl.so" show?

> yajl got and installed from git rep:
> 
> cd
> git clone git://github.com/lloyd/yajl

Which version of yajl is this? Why don't you just "apt-get install
libyajl-dev"? Or at least use a released version.

> cd yajl
> sudo apt-get install ruby cmake
> ./configure
> make
> sudo make install
> 
> install was successful
> 
> 
> 
> 

Re: compiling error "xen-unstable.hg"

[Ian Campbell]

You have dropped xen-devel again. I have put it back again this time. In
the future I will ignore mails from you which do not CC the list.

On Fri, 2012-07-27 at 10:45 +0100, Yuriy Logvinov wrote:
> :
> 
> 
>         Please keep the list on the CC line so that everyone can
>         benefit. I've
>         put it back for you this time.
>         
>         On Fri, 2012-07-27 at 10:16 +0100, Yuriy Logvinov wrote:
>         > > > but now i have this error: 
>         > > >...
>         > >
>         >
>         > /home/alex/xen-unstable.hg/tools/libxl/../../tools/libxl/libxenlight.so:
>         > > > undefined reference to `yajl_complete_parse'
>         > > 
>         > > Unsupported/wrong libyajl version (I don't recall whether
>         support
>         > > for v2 of the library was ever added).
>         > 
>         > It was.
>         > 
>         > configure has a check for yajl/yajl_version.h and
>         > tools/libxl/libxl_json.h uses this to determine v1 vs v2
>         (and assumes
>         > v1
>         > if it is not present).
>         > 
>         > What does "grep YAJL tools/config.h" say?
>         > 
>         > Ian.
>         
>         > grep YAJL tools/config.h:
>         > 
>         > 
>         > #define HAVE_LIBYAJL 1
>         > #define HAVE_YAJL_YAJL_VERSION_H 1
>         
>         What does /usr/incude/yajl/yajl_version.h contain?
> 
> it contain:
> #define YAJL_MAJOR 1
> #define YAJL_MINOR 0
> #define YAJL_MICRO 12

Which indicates version 1.0.12 of yajl, yet the git URL you quoted
before contains 2.0.5.

I think you've got your system into an inconsistent state, with multiple
incompatible versions of yajl on it.

> /usr/local/lib/libyajl.so: file format elf64-x86-64
[...]
> 0000000000001540 g DF .text 000000000000003d Base yajl_complete_parse

This implies a 2.0.x version also.

> i have libyajl.so in /usr/local/lib/ folder not /usr/lib/ may be it`s
> important ?

Yes, you need to clean up all the rubbish you installed by hand and make
sure your system is in a consistent state before you try installing Xen
again. I suggest you ask for help on how to do this from the Ubuntu user
forums or somewhere like that -- it's not a Xen issue.

Ian.

Re: compiling error "xen-unstable.hg"

[Jan Beulich]

>>> On 27.07.12 at 11:23, Yuriy Logvinov<hackroute@mail.ru> wrote:
>>  when i compiling xen-unstable.hg from
>> 'http://xenbits.xen.org/hg/xen-unstable.hg' or staging reps
>> i have an error 
>> 
>> sed: -e expression #6, symbol 111:command not finished `s' 
>> make[2]: *** [include/xen/compile.h] error 1 
>> 
>> /xen-unstable.hg/xen/makefile:
>> ...
>> # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
>> include/xen/compile.h: include/xen/compile.h.in .banner
>> @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
>> ...
>> -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) -v 2>&1 | grep version |
>> tail -1)!g' \
>> ...
>> -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date}
>> {rev}:{node|short}" >/dev/null && hg parents --template "{date|date}
>> {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
>> < include/xen/compile.h.in > $@.new
>> ...
>> 
>> i remove " | grep version"
>> and it fixed this error
> 
> But that's certainly not the right fix. What output does
> "$(CC) $(CFLAGS) -v" produce for you? In particular, does it
> perhaps include any single quote character(s)?
> 
>  Jan
> 
> after remove grep version i get in compile.h:
> #define XEN_COMPILER        "gcc версия 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
> "
> 
> what should i get in this identifier?
>  "gcc"? Or "4.6.3" or what?

The resulting string is correct, and the grep simply doesn't work
because you have a localized gcc. The addition of grep here was
done to support clang (see c/s 22985:d8ea33e7af7e, author
Cc-ed). It's not clear to me how to get around such translation
issues (Tim - could you explain what output clang generates that
made the use of grep necessary?), nor do I have a clue why the
sed invocation would complain about an unfinished command
(from what you provided I'd suppose that it would end up with
an empty replacement string, which ought to be fine).

Jan

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

Re: compiling error "xen-unstable.hg"

[Ian Campbell]

On Fri, 2012-07-27 at 11:14 +0100, Jan Beulich wrote:
> >>> On 27.07.12 at 11:23, Yuriy Logvinov<hackroute@mail.ru> wrote:
> >>  when i compiling xen-unstable.hg from
> >> 'http://xenbits.xen.org/hg/xen-unstable.hg' or staging reps
> >> i have an error 
> >> 
> >> sed: -e expression #6, symbol 111:command not finished `s' 
> >> make[2]: *** [include/xen/compile.h] error 1 
> >> 
> >> /xen-unstable.hg/xen/makefile:
> >> ...
> >> # compile.h contains dynamic build info. Rebuilt on every 'make' invocation.
> >> include/xen/compile.h: include/xen/compile.h.in .banner
> >> @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
> >> ...
> >> -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) -v 2>&1 | grep version |
> >> tail -1)!g' \
> >> ...
> >> -e 's!@@changeset@@!$(shell ((hg parents --template "{date|date}
> >> {rev}:{node|short}" >/dev/null && hg parents --template "{date|date}
> >> {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
> >> < include/xen/compile.h.in > $@.new
> >> ...
> >> 
> >> i remove " | grep version"
> >> and it fixed this error
> > 
> > But that's certainly not the right fix. What output does
> > "$(CC) $(CFLAGS) -v" produce for you? In particular, does it
> > perhaps include any single quote character(s)?
> > 
> >  Jan
> > 
> > after remove grep version i get in compile.h:
> > #define XEN_COMPILER        "gcc версия 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
> > "
> > 
> > what should i get in this identifier?
> >  "gcc"? Or "4.6.3" or what?
> 
> The resulting string is correct, and the grep simply doesn't work
> because you have a localized gcc. The addition of grep here was
> done to support clang (see c/s 22985:d8ea33e7af7e, author
> Cc-ed). It's not clear to me how to get around such translation
> issues

A judicious sprinkling of LANG=C  or LC_ALL=C etc?

>  (Tim - could you explain what output clang generates that
> made the use of grep necessary?), nor do I have a clue why the
> sed invocation would complain about an unfinished command

Perhaps one of the multibyte Russian characters contains a "!" which
confuses non-UTF8 aware sed?

> (from what you provided I'd suppose that it would end up with
> an empty replacement string, which ought to be fine).
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

Re: compiling error "xen-unstable.hg"

[Jan Beulich]

>>> On 27.07.12 at 12:25, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-07-27 at 11:14 +0100, Jan Beulich wrote:
>> The resulting string is correct, and the grep simply doesn't work
>> because you have a localized gcc. The addition of grep here was
>> done to support clang (see c/s 22985:d8ea33e7af7e, author
>> Cc-ed). It's not clear to me how to get around such translation
>> issues
> 
> A judicious sprinkling of LANG=C  or LC_ALL=C etc?

Yuriy, could you give this a try?

>>  (Tim - could you explain what output clang generates that
>> made the use of grep necessary?), nor do I have a clue why the
>> sed invocation would complain about an unfinished command
> 
> Perhaps one of the multibyte Russian characters contains a "!" which
> confuses non-UTF8 aware sed?

But the grep should not have returned anything, hence none
of those characters would even be seen by sed. Plus UTF-8
encodings of characters outside the ASCII range have their
high bits set on all resulting bytes (to avoid this very problem).

Jan

Re: compiling error "xen-unstable.hg"

[Juergen Gross]

Am 27.07.2012 12:38, schrieb Jan Beulich:
>>>> On 27.07.12 at 12:25, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
>> On Fri, 2012-07-27 at 11:14 +0100, Jan Beulich wrote:
>>> The resulting string is correct, and the grep simply doesn't work
>>> because you have a localized gcc. The addition of grep here was
>>> done to support clang (see c/s 22985:d8ea33e7af7e, author
>>> Cc-ed). It's not clear to me how to get around such translation
>>> issues
>>
>> A judicious sprinkling of LANG=C  or LC_ALL=C etc?
>
> Yuriy, could you give this a try?
>
>>>   (Tim - could you explain what output clang generates that
>>> made the use of grep necessary?), nor do I have a clue why the
>>> sed invocation would complain about an unfinished command
>>
>> Perhaps one of the multibyte Russian characters contains a "!" which
>> confuses non-UTF8 aware sed?
>
> But the grep should not have returned anything, hence none
> of those characters would even be seen by sed. Plus UTF-8
> encodings of characters outside the ASCII range have their
> high bits set on all resulting bytes (to avoid this very problem).

The grep returns the "Configured with:..." string on my system which contains
something like

  --with-pkgversion='Debian 4.4.5-8'

resulting in the sed error, as the tail -1 won't return the gcc version line.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Re: compiling error "xen-unstable.hg"

[Tim Deegan]

At 12:58 +0200 on 27 Jul (1343393923), Juergen Gross wrote:
> Am 27.07.2012 12:38, schrieb Jan Beulich:
> >>>>On 27.07.12 at 12:25, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
> >>On Fri, 2012-07-27 at 11:14 +0100, Jan Beulich wrote:
> >>>The resulting string is correct, and the grep simply doesn't work
> >>>because you have a localized gcc. The addition of grep here was
> >>>done to support clang (see c/s 22985:d8ea33e7af7e, author
> >>>Cc-ed). It's not clear to me how to get around such translation
> >>>issues
> >>
> >>A judicious sprinkling of LANG=C  or LC_ALL=C etc?
> >
> >Yuriy, could you give this a try?
> >
> >>>  (Tim - could you explain what output clang generates that
> >>>made the use of grep necessary?), nor do I have a clue why the
> >>>sed invocation would complain about an unfinished command

clang -v prints something like this:

Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

so unlike GCC you can't just take the last line of the output.  Grepping
for version was intended to get rid of the other chatter, but clearly
it's broken in the face of localized version strings.  

We might do better to switch to '$(CC) --version | head -1', which seems
to provide something sensible on all the gcc and clang binaries I have
handy. 

Tim.

Re: compiling error "xen-unstable.hg"

[Jan Beulich]

>>> On 27.07.12 at 22:29, Tim Deegan <tim@xen.org> wrote:
> At 12:58 +0200 on 27 Jul (1343393923), Juergen Gross wrote:
>> Am 27.07.2012 12:38, schrieb Jan Beulich:
>> >>>>On 27.07.12 at 12:25, Ian Campbell<Ian.Campbell@citrix.com>  wrote:
>> >>On Fri, 2012-07-27 at 11:14 +0100, Jan Beulich wrote:
>> >>>The resulting string is correct, and the grep simply doesn't work
>> >>>because you have a localized gcc. The addition of grep here was
>> >>>done to support clang (see c/s 22985:d8ea33e7af7e, author
>> >>>Cc-ed). It's not clear to me how to get around such translation
>> >>>issues
>> >>
>> >>A judicious sprinkling of LANG=C  or LC_ALL=C etc?
>> >
>> >Yuriy, could you give this a try?
>> >
>> >>>  (Tim - could you explain what output clang generates that
>> >>>made the use of grep necessary?), nor do I have a clue why the
>> >>>sed invocation would complain about an unfinished command
> 
> clang -v prints something like this:
> 
> Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> 
> so unlike GCC you can't just take the last line of the output.  Grepping
> for version was intended to get rid of the other chatter, but clearly
> it's broken in the face of localized version strings.  
> 
> We might do better to switch to '$(CC) --version | head -1', which seems
> to provide something sensible on all the gcc and clang binaries I have
> handy. 

The question is how relevant that string is in the first place:
My cross compilers, for example, get invoked through a shell
scripts that's named gccx. Invoking that with --version
reproduces the shell script name (which the script forces as
the argv[0] of the exec-ed "real" gcc):

gccx (GCC) 4.7.1

which isn't the case for -v:

gcc version 4.7.1 (GCC)

So as long as no deeper meaning is implied from the string by
anyone (there's nothing in-tree that I'm aware of), I think
that's at least as good a change as adding LC_ALL=C (of
which I'm not really certain whether it would be fully reliable
in all possible cases).

Jan

Re: compiling error "xen-unstable.hg"

[Tim Deegan]

At 08:27 +0100 on 30 Jul (1343636877), Jan Beulich wrote:
> > We might do better to switch to '$(CC) --version | head -1', which seems
> > to provide something sensible on all the gcc and clang binaries I have
> > handy. 
> 
> The question is how relevant that string is in the first place:
> My cross compilers, for example, get invoked through a shell
> scripts that's named gccx. Invoking that with --version
> reproduces the shell script name (which the script forces as
> the argv[0] of the exec-ed "real" gcc):
> 
> gccx (GCC) 4.7.1
> 
> which isn't the case for -v:
> 
> gcc version 4.7.1 (GCC)

Sigh.  

> So as long as no deeper meaning is implied from the string by
> anyone (there's nothing in-tree that I'm aware of), I think
> that's at least as good a change as adding LC_ALL=C (of
> which I'm not really certain whether it would be fully reliable
> in all possible cases).

I'm not aware of anyone/anything that relies on that string except for
human consumption.  I'll submit a patch to change to --version. 

Cheers,

Tim.