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
>>> 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 errorBut 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
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.
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 1What 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/yajlWhich 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 > > > >
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 12Which 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_parseThis 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.
>>> 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
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 > issuesA 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 commandPerhaps 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
>>> 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
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
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 commandclang -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.
>>> 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
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.