Created attachment 4406 [details] configuration file buildroot Hello, I have attached the config file that reproduces this bug (basically i think to reproduce this bug what you need to do is try to build the libglib2). The following final error is given: SyntaxErrorSyntaxError: : Non-ASCII character '\xd0' in file ../../gio/gdbus-2.0/codegen/gdbus-codegen on line 36, but no encoding declared; see http://www.python.org/peps/pep-0263.html for detailsNon-ASCII character '\xd0' in file ../../gio/gdbus-2.0/codegen/gdbus-codegen on line 36, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details Anton PS This is a very strange bug. Honestly i was expecting that such standard libraries are building correctly by now.
Can you attach the last 100-150 lines of the build log? What is the version of Python installed on your host machine?
I have taken your .config, and the build ended succesfully, so I strongly suspect something on your host that influences the build. Can you attach the file output/build/libglib-2.30.2/gio/gdbus-2.0/codegen/gdbus-codegen ?
(In reply to comment #1) > Can you attach the last 100-150 lines of the build log? > > What is the version of Python installed on your host machine? $ python3.1 --version Python 3.1.2 $ python --version Python 2.6.5 What version should it be? How can i pass the correct python version to the build system? Shouldn't you check the python version before doing the build?
(In reply to comment #2) > I have taken your .config, and the build ended succesfully, so I strongly > suspect something on your host that influences the build. I also suspect this, but shouldn't the build script check for such things? (like the python version) > > Can you attach the file > output/build/libglib-2.30.2/gio/gdbus-2.0/codegen/gdbus-codegen ? It gets deleted, after the build ends with an error.
I have an idea. Can you tell me what is the full path to your Buildroot directory?
(In reply to comment #4) > (In reply to comment #2) > > I have taken your .config, and the build ended succesfully, so I strongly > > suspect something on your host that influences the build. > > I also suspect this, but shouldn't the build script check for such things? > (like the python version) Currently, there is no check to check/detect python version, but there are few patches about that in the pipe: http://patchwork.ozlabs.org/patch/162456/ http://patchwork.ozlabs.org/patch/162457/ Note that in your case, 'python' points to python2.x while 'python3' to python3.x, which is the standard currently. So, the problem is not here. BTW, these 2 patches intend to fix this kind of issues on system/distro, such as archlinux, in which 'python' points to python3.
(In reply to comment #5) > I have an idea. Can you tell me what is the full path to your Buildroot > directory? /home/<user name>/<name in cyrillic chars>/buildroot/latest/buildroot
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #2) > > > I have taken your .config, and the build ended succesfully, so I strongly > > > suspect something on your host that influences the build. > > > > I also suspect this, but shouldn't the build script check for such things? > > (like the python version) > > Currently, there is no check to check/detect python version, but there are few > patches about that in the pipe: > http://patchwork.ozlabs.org/patch/162456/ > http://patchwork.ozlabs.org/patch/162457/ > > Note that in your case, 'python' points to python2.x while 'python3' to > python3.x, which is the standard currently. So, the problem is not here. > > BTW, these 2 patches intend to fix this kind of issues on system/distro, such > as archlinux, in which 'python' points to python3. What python version should be enough to do the build?
The name is cyrilic chars is the problem. This gdbus-codegen Python script is generated from gdbus-codegen.in by replacing some paths into the script. And as the script doesn't declare any encoding, it doesn't like having non-ascii characters into the path. This also explains why it was working for me. One option is to declare the script encoding as utf-8, but that would only work on utf-8 configured systems. On other systems, it would probably not work. This problem is not Buildroot's fault, so I think it should rather be reported to the glib maintainers.
(In reply to comment #9) > The name is cyrilic chars is the problem. Yes. You are right. After moving the directory the build was successful. After extending the package list i got a new error, output/build/gcc-4.7.1-target/arm-unknown-linux-uclibcgnueabi/libstdc++-v3/include/fenv.h:36:24 can't find fenv.h I have included the new config file as an attachment > This gdbus-codegen Python script is > generated from gdbus-codegen.in by replacing some paths into the script. And as > the script doesn't declare any encoding, it doesn't like having non-ascii > characters into the path. This also explains why it was working for me. > > One option is to declare the script encoding as utf-8, but that would only work > on utf-8 configured systems. On other systems, it would probably not work. This > problem is not Buildroot's fault, so I think it should rather be reported to > the glib maintainers.
Created attachment 4412 [details] new config file the build ends with the can't find fenv.h file error.
(In reply to comment #11) > Created attachment 4412 [details] > new config file > > the build ends with the can't find fenv.h file error. fenv.h comes with uClibc when C99 floating point environment is enabled. This feature is disabled in the default uclibc-0.9.33 defconfig file. You can change this running 'make uclibc-menuconfig' in "Target Architecture Features and Options >> Enable C99 Floating-point environment", but this will require to rebuild the cross-toolchain.
(In reply to comment #12) > (In reply to comment #11) > > Created attachment 4412 [details] > > new config file > > > > the build ends with the can't find fenv.h file error. > > fenv.h comes with uClibc when C99 floating point environment is enabled. > This feature is disabled in the default uclibc-0.9.33 defconfig file. > > You can change this running 'make uclibc-menuconfig' in "Target Architecture > Features and Options >> Enable C99 Floating-point environment", but this will > require to rebuild the cross-toolchain. It builds now perfectly. Thank you! PS How would i have know to run 'make uclibc-menuconfig' ... ? There was no such problem in the previous version (release) of buildroot.
On which package did the fenv.h build problem occured? Also, could you report your libglib2 problem to the upstream libglib developers?
(In reply to comment #14) > On which package did the fenv.h build problem occured? > > Also, could you report your libglib2 problem to the upstream libglib > developers? yes, i can.
(In reply to comment #14) > On which package did the fenv.h build problem occured? > > Also, could you report your libglib2 problem to the upstream libglib > developers? It's at https://bugzilla.gnome.org/show_bug.cgi?id=679993
(In reply to comment #14) > On which package did the fenv.h build problem occured? > > Also, could you report your libglib2 problem to the upstream libglib > developers? This is crazy... Now I can't login. (In the previous build of buildroot i had no problem, at least after i disabled WCHAR). I can login if i remove the 'x' from the second field of the /etc/passwd file. The rest of the files (securitty, inittab) look fine (unaltered).
(In reply to comment #14) > On which package did the fenv.h build problem occured? I think it is the gcc package for the target, that is "gcc-4.7.1-target".
Original problem is "solved": it is an upstream glib2 bug which has been reported at https://bugzilla.gnome.org/show_bug.cgi?id=679993.