Issue 319400043: Fix build failure on GNU Hurd (Closed)
|
Created:
8 years, 2 months ago by pkx166h Modified:
8 years, 2 months ago CC:
lilypond-devel_gnu.org, fede_inventati.org Visibility:
Public. |
DescriptionFix build failure on GNU Hurd
Issue 5077
LilyPond failed to build on
GNU Hurd because Hurd does
not have PATH_MAX.
The cause seem to be a typo
in the file
debian/patches/hurd_file_name_support,
checking for _GNU_SOURCE_
instead of _GNU_SOURCE
(at least that is what
the getcwd() manual page
claim to look for).
Patch Set 1 #
MessagesTotal messages: 10
This passes make and a full make doc, but I cannot run the usual pattern of
make,
make test-baseline
apply patch
make clean
make
make check
make doc
It fails on the second 'make' (after make clean) ..
--snip---
tml
mkdir -p ./out
touch ./out/dummy.dep
echo '*' > ./out/.gitignore
For tracking crashes: use
grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed
s/log/ly/g`
make --no-builtin-rules -C input/regression out=test local-test
make[1]: Entering directory '/home/jlowe/lilypond-git/build/input/regression'
mkdir -p ./out-test
touch ./out-test/dummy.dep
echo '' > ./out-test/.gitignore
rm -f ./out-test/collated-files.html
if test -d /home/jlowe/lilypond-git/.git ; then \ echo -e 'HEAD is:\n\n\t' ; \
(cd /home/jlowe/lilypond-git && git log --max-count=1 --pretty=oneline ) ;\ echo
-e '\n\n\n' ; \ (cd /home/jlowe/lilypond-git && git diff ) ; \ fi >
./out-test/tree.gittxt
make LILYPOND_BOOK_LILYPOND_FLAGS="-dbackend=eps --formats=ps -djob-count=4
-dseparate-log-files -dinclude-eps-fonts -dgs-load-lily-fonts --header=texidoc
-I /home/jlowe/lilypond-git/Documentation/included/ -ddump-profile
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1"
LILYPOND_BOOK_WARN= ./out-test/collated-files.html
LYS_OUTPUT_DIR=/home/jlowe/lilypond-git/build/out/lybook-testdb
make[2]: Entering directory '/home/jlowe/lilypond-git/build/input/regression'
/usr/bin/python -tt
/home/jlowe/lilypond-git/scripts/build/create-version-itexi.py >
out-test/version.itexi
/usr/bin/python -tt
/home/jlowe/lilypond-git/scripts/build/create-weblinks-itexi.py >
out-test/weblinks.itexi
/home/jlowe/lilypond-git/build/scripts/build/out/lys-to-tely
--name=./out-test/collated-files.tely --title="LilyPond Regression Tests"
--author="Han-Wen Nienhuys and Jan Nieuwenhuizen"
--input-filename=out-test/collated-files.list
/bin/sh: 1: /home/jlowe/lilypond-git/build/scripts/build/out/lys-to-tely: not
found
/home/jlowe/lilypond-git/./make/lysdoc-rules.make:19: recipe for target
'out-test/collated-files.tely' failed
make[2]: [out-test/collated-files.tely] Error 127
make[2]: Waiting for unfinished jobs....
Traceback (most recent call last):
File "/home/jlowe/lilypond-git/scripts/build/create-weblinks-itexi.py", line 15,
in <module>
import langdefs
ImportError: No module named langdefs
/home/jlowe/lilypond-git/stepmake/stepmake/texinfo-rules.make:95: recipe for
target 'out-test/weblinks.itexi' failed
make[2]: [out-test/weblinks.itexi] Error 1
make[2]: Leaving directory '/home/jlowe/lilypond-git/build/input/regression'
/home/jlowe/lilypond-git/./make/lysdoc-targets.make:12: recipe for target
'local-test' failed
make[1]: [local-test] Error 2
make[1]: Leaving directory '/home/jlowe/lilypond-git/build/input/regression'
/home/jlowe/lilypond-git/GNUmakefile.in:308: recipe for target 'test' failed
make: ** [test] Error 2
--snip--
Is this something that is bound to happen and cannot be tested normally or is
this something that the patch submitter didn't take into account on our side or
something else such as a specific configuration environment that isn't
universal?
Sign in to reply to this message.
The fix probably breaks compilation on everything not using glibc:
get_current_dir_name() is glibc specific, and not available on other
systems, so its invocation should be protected with an #ifdef __GLIBC__
or via an autoconf test.
As indicated in the man page, even on glibc, to use this function a
declaration of _GNU_SOURCE before including the system headers is
necessary. However in the case of lilypond, as a C++ program, this is
not necessary since g++ (and clang++) predefine _GNU_SOURCE.
glibc has an extension to getcwd. (It allocates the buffer when its
first argument is NULL.) Maybe the following works and is more
portable:
string
get_working_directory ()
{
char *cwd = getcwd (NULL, 0);
#ifdef PATH_MAX
if (!cwd)
{
char scwd[PATH_MAX];
return string (getcwd (scwd, PATH_MAX));
}
#endif
string s(cwd);
free(cwd);
return s;
}
Sign in to reply to this message.
On 2017/02/25 15:19:47, felix.janda_posteo.de wrote:
> The fix probably breaks compilation on everything not using glibc:
>
> get_current_dir_name() is glibc specific, and not available on other
> systems, so its invocation should be protected with an #ifdef __GLIBC__
> or via an autoconf test.
>
> As indicated in the man page, even on glibc, to use this function a
> declaration of _GNU_SOURCE before including the system headers is
> necessary. However in the case of lilypond, as a C++ program, this is
> not necessary since g++ (and clang++) predefine _GNU_SOURCE.
>
> glibc has an extension to getcwd. (It allocates the buffer when its
> first argument is NULL.) Maybe the following works and is more
> portable:
>
> string
> get_working_directory ()
> {
> char *cwd = getcwd (NULL, 0);
> #ifdef PATH_MAX
> if (!cwd)
> {
> char scwd[PATH_MAX];
> return string (getcwd (scwd, PATH_MAX));
> }
> #endif
> string s(cwd);
> free(cwd);
> return s;
> }
I am going to need some help from a developer on this as not being a programmer
I don't know what that last comment means I need to do on my side.
Thanks
Sign in to reply to this message.
On 2017/03/04 18:03:37, pkx166h wrote: > I am going to need some help from a developer on this as not being a programmer > I don't know what that last comment means I need to do on my side. I've tried Patch Set 1. I could not reproduce errors. Would you show me your environment and detailed reproduction procedure? I've succeeded the following commands in my environment. $ git fetch $ git checkout master $ git merge origin/master $ ./autogen.sh --noconf $ rm -fr build $ mkdir build $ cd build $ ../configure $ make -j 4 CPU_COUNT=4 $ make -j 4 CPU_COUNT=4 test-baseline $ cd .. $ git apply ~/issue319400043_1.diff $ cd build $ make clean $ make -j 4 CPU_COUNT=4 In another word, the second `make` (after `make clean`) has succeeded. However, next command $ make -j 4 CPU_COUNT=4 check `make check` has failed. The cause of the error that occurred in my environment seems to be multiple definition of the same name function. I think that it is easy to fix. But, the error that occurred in your environment is unknown.
Sign in to reply to this message.
2017-03-04 19:03 GMT+01:00 <pkx166h@gmail.com>: > On 2017/02/25 15:19:47, felix.janda_posteo.de wrote: >> >> The fix probably breaks compilation on everything not using glibc: Is lilypond supposed to be built on anything outside GNU/Linux?
Sign in to reply to this message.
Benkő Pál <benko.pal@gmail.com> writes: > 2017-03-04 19:03 GMT+01:00 <pkx166h@gmail.com>: >> On 2017/02/25 15:19:47, felix.janda_posteo.de wrote: >>> >>> The fix probably breaks compilation on everything not using glibc: > > Is lilypond supposed to be built on anything outside GNU/Linux? More or less yes. Heeding reports and warnings outside of GNU/Linux make us more robust against relying on features and quirks specific to current versions of GCC (which has a tendency to retire everything not making it into C++ standards) and possibly certain platforms. It's not a priority, but we tend to try keeping up with the other world. Recently there were reports about overloading problems with Clang++ that I decided _not_ working around since a) it was a clear compiler error of Clang++ in heeding the standard, so there was reasonable expectation that Clang++ would eventually get around to fixing it. b) workarounds would have definitely impacted the maintainability of the code base. But in general, we do try to "play nice" where it doesn't cost us significantly. -- David Kastrup
Sign in to reply to this message.
On 2017/03/08 11:43:26, trueroad wrote:
> On 2017/03/04 18:03:37, pkx166h wrote:
> > I am going to need some help from a developer on this as not being a
> programmer
> > I don't know what that last comment means I need to do on my side.
>
> I've tried Patch Set 1.
> I could not reproduce errors.
> Would you show me your environment and detailed reproduction procedure?
>
> I've succeeded the following commands in my environment.
>
> $ git fetch
> $ git checkout master
> $ git merge origin/master
> $ ./autogen.sh --noconf
> $ rm -fr build
> $ mkdir build
> $ cd build
> $ ../configure
> $ make -j 4 CPU_COUNT=4
> $ make -j 4 CPU_COUNT=4 test-baseline
> $ cd ..
> $ git apply ~/issue319400043_1.diff
> $ cd build
> $ make clean
> $ make -j 4 CPU_COUNT=4
>
> In another word, the second `make` (after `make clean`) has succeeded.
> However, next command
>
> $ make -j 4 CPU_COUNT=4 check
>
> `make check` has failed.
>
> The cause of the error that occurred in my environment seems to be multiple
> definition of the same name function.
> I think that it is easy to fix.
>
> But, the error that occurred in your environment is unknown.
Hello Hosoda-san,
My error message is similar it is this:
rm -f ./out/test-std.dep; DEPENDENCIES_OUTPUT="./out/test-std.dep
./out/test-std.o" g++ -c -I/usr/include/python2.7
-I/usr/include/x86_64-linux-gnu/python2.7 -fno-strict-aliasing -g
-fstack-protector-strong -g -fwrapv -DHAVE_CONFIG_H -DDEBUG
-I/home/jlowe/lilypond-git/flower/include -I./out
-I/home/jlowe/lilypond-git/flower/include -I../flower/./out
-I/home/jlowe/lilypond-git/flower/out -g -pipe -pthread
-I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -W -Wall
-Wconversion -o out/test-std.o /home/jlowe/lilypond-git/flower/test-std.cc
In file included from /home/jlowe/lilypond-git/flower/test-file-path.cc:6:0:
/home/jlowe/lilypond-git/flower/include/yaffut.hh: In member function 'int
yaffut::Factory::Main(int, const char**)':
/home/jlowe/lilypond-git/flower/include/yaffut.hh:212:39: warning: conversion to
'int' from 'size_t {aka long unsigned int}' may alter its value [-Wconversion]
return Factory::Instance ().Fail ();
^
In file included from
/home/jlowe/lilypond-git/flower/include/yaffut-parameters.hh:4:0,
from /home/jlowe/lilypond-git/flower/test-file-name.cc:3:
/home/jlowe/lilypond-git/flower/include/yaffut.hh: In member function 'int
yaffut::Factory::Main(int, const char**)':
/home/jlowe/lilypond-git/flower/include/yaffut.hh:212:39: warning: conversion to
'int' from 'size_t {aka long unsigned int}' may alter its value [-Wconversion]
return Factory::Instance ().Fail ();
^
In file included from /home/jlowe/lilypond-git/flower/test-string.cc:6:0:
/home/jlowe/lilypond-git/flower/include/yaffut.hh: In member function 'int
yaffut::Factory::Main(int, const char**)':
/home/jlowe/lilypond-git/flower/include/yaffut.hh:212:39: warning: conversion to
'int' from 'size_t {aka long unsigned int}' may alter its value [-Wconversion]
return Factory::Instance ().Fail ();
^
In file included from /home/jlowe/lilypond-git/flower/test-std.cc:7:0:
/home/jlowe/lilypond-git/flower/include/yaffut.hh: In member function 'int
yaffut::Factory::Main(int, const char**)':
/home/jlowe/lilypond-git/flower/include/yaffut.hh:212:39: warning: conversion to
'int' from 'size_t {aka long unsigned int}' may alter its value [-Wconversion]
return Factory::Instance ().Fail ();
^
rm -f ./out/test-interval-set.dep;
DEPENDENCIES_OUTPUT="./out/test-interval-set.dep ./out/test-interval-set.o" g++
-c -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7
-fno-strict-aliasing -g -fstack-protector-strong -g -fwrapv -DHAVE_CONFIG_H
-DDEBUG -I/home/jlowe/lilypond-git/flower/include -I./out
-I/home/jlowe/lilypond-git/flower/include -I../flower/./out
-I/home/jlowe/lilypond-git/flower/out -g -pipe -pthread
-I/usr/include/freetype2 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -W -Wall
-Wconversion -o out/test-interval-set.o
/home/jlowe/lilypond-git/flower/test-interval-set.cc
In file included from /home/jlowe/lilypond-git/flower/test-interval-set.cc:22:0:
/home/jlowe/lilypond-git/flower/include/yaffut.hh: In member function 'int
yaffut::Factory::Main(int, const char**)':
/home/jlowe/lilypond-git/flower/include/yaffut.hh:212:39: warning: conversion to
'int' from 'size_t {aka long unsigned int}' may alter its value [-Wconversion]
return Factory::Instance ().Fail ();
^
/home/jlowe/lilypond-git/flower/include/yaffut.hh: In instantiation of 'void
yaffut::equal(const Expected&, const Actual&, const char*, const char*) [with
Expected = long unsigned int; Actual = int]':
/home/jlowe/lilypond-git/flower/test-interval-set.cc:35:3: required from here
/home/jlowe/lilypond-git/flower/include/yaffut.hh:326:9: warning: comparison
between signed and unsigned integer expressions [-Wsign-compare]
if (e != a)
^
make -C ../flower && true
make[2]: Entering directory '/home/jlowe/lilypond-git/build/flower'
true
make[2]: Leaving directory '/home/jlowe/lilypond-git/build/flower'
g++ -o out/test-flower ./out/test-file-name.o ./out/test-string.o
./out/test-file-path.o ./out/test-std.o ./out/test-interval-set.o
./out/../../flower/out/library.a
./out/../../flower/out/library.a(file-name.o): In function
`get_working_directory[abi:cxx11]()':
/home/jlowe/lilypond-git/flower/file-name.cc:79: multiple definition of
`get_working_directory[abi:cxx11]()'
./out/test-file-path.o:/home/jlowe/lilypond-git/flower/test-file-path.cc:11:
first defined here
collect2: error: ld returned 1 exit status
/home/jlowe/lilypond-git/stepmake/stepmake/test-rules.make:10: recipe for target
'out/test-flower' failed
make[1]: *** [out/test-flower] Error 1
make[1]: Leaving directory '/home/jlowe/lilypond-git/build/flower'
/home/jlowe/lilypond-git/stepmake/stepmake/generic-targets.make:141: recipe for
target 'check' failed
make: *** [check] Error 2
Sign in to reply to this message.
On 2017/03/08 17:36:40, pkx166h wrote: > My error message is similar it is this: Thank you for showing your error message. It looks the same as mine. I've created a patch for fixing `make check` error only. Would you try it? https://sourceforge.net/p/testlilyissues/issues/5077/#28bc This patch has worked in Cygwin (non-glibc) environment. It also might work in Linux (of course glibc) environment. (Sorry, I've not tried it.) However, portability that Felix says is not considered. If this patch works in your environment, I would like to consider a more portable way.
Sign in to reply to this message.
I've created new Rietveld issue and uploaded new patches because I could not upload them to this issue. https://codereview.appspot.com/320360043/
Sign in to reply to this message.
Closed as it is being worked on in https://codereview.appspot.com/320360043/
Sign in to reply to this message.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
