[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Alexey Brodkin]

Hi Thomas,

On Mon, 2015-06-29 at 08:30 +0200, Thomas Petazzoni wrote:
> Those results are limited to the arc architecture.
> 
> Build statistics for 2015-06-28
> ===============================
> 
>         success : 10 
>        failures : 9  
>        timeouts : 0  
>           TOTAL : 19 
> 
Classification of failures by reason
> ====================================
> 
>              berkeleydb-5.3.28 | 2 
>                  empty-0.6.19b | 2 
>                    tor-0.2.6.9 | 1 
>                    eudev-3.1.1 | 1 
>       binutils-arc-2015.06-rc1 | 1 
>                   zeromq-4.0.5 | 1 
>                  lvm2-2.02.121 | 1 
> 
> Detail of failures
> ===================
> 
>          arc |              berkeleydb-5.3.28 | NOK | http://autobuil
> d.buildroot.net/results/717f3b37600a56262badc6f7cb64d7949fdacb67/
>          arc |              berkeleydb-5.3.28 | NOK | 
> http://autobuild.buildroot.net/results/80ebf0382992b277fd94743815bbf0
> c7426a3654/

That's a failure if toolchain is configured without threads.
This is what I see in config.log:
--------------------->8--------------------
configure:20510: checking for mutexes
configure:20603:
/home/abrodkin/Outputs/buildroot/test2/host/usr/bin/arc-buildroot-linux
-uclibc-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
-D_FILE_OFFSET_BITS=64 -matomic  -Os -g2  -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT
  conftest.c  -lpthread >&5
In file included from
/home/abrodkin/Outputs/buildroot/test2/host/usr/arc-buildroot-linux
-uclibc/sysroot/usr/include/stdlib.h:24:0,
                 from conftest.c:43:
/home/abrodkin/Outputs/buildroot/test2/host/usr/arc-buildroot-linux
-uclibc/sysroot/usr/include/features.h:208:5: warning: #warning
requested reentrant code, but thread support was disabled [-Wcpp]
 #   warning requested reentrant code, but thread support was disabled
     ^
conftest.c:44:21: fatal error: pthread.h: No such file or directory
 #include <pthread.h>
                     ^
compilation terminated.
--------------------->8--------------------

Fixed with http://patchwork.ozlabs.org/patch/491656/

>          arc |       binutils-arc-2015.06-rc1 | NOK | 
> http://autobuild.buildroot.net/results/53d333850a82f71c4e708926d35190
> 93282a6cdf/

I was not able to reproduce that one and from build log I may assume
build process was terminated from outside ("ld terminated with signal 6
[Aborted]"). Is there a chance that build server was shut down or
something?
--------------------->8--------------------
libtool: link: /home/peko/autobuild/instance-0/output/host/usr/bin/arc
-buildroot-linux-uclibc-gcc -shared  .libs/dis-buf.o
.libs/disassemble.o .libs/dis-init.o .libs/arc-asm.o .libs/arcompact
-dis.o .libs/arc-ext.o .libs/arc-desc.o .libs/arc-dis-old.o .libs/arc
-dis.o .libs/arc-ibld.o .libs/arc-opc-old.o .libs/arc-opc.o .libs/arc
-opinst.o .libs/cgen-opc.o .libs/cgen-asm.o .libs/cgen-dis.o .libs/cgen
-bitset.o   -L/home/peko/autobuild/instance-0/output/build/binutils-arc
-2015.06-rc1/opcodes/../libiberty/pic -liberty  -matomic 
-Wl,/home/peko/autobuild/instance-0/output/build/binutils-arc-2015.06
-rc1/opcodes/../bfd/.libs/libbfd.so -Wl,-lc -Wl,--as-needed -Wl,-lm 
-Wl,--no-as-needed   -Wl,-soname -Wl,libopcodes-2.23.2.so -o
.libs/libopcodes-2.23.2.so
collect2: error: ld terminated with signal 6 [Aborted]
make[5]: *** [libopcodes.la] Error 1
--------------------->8--------------------

>          arc |                  empty-0.6.19b | NOK | 
> http://autobuild.buildroot.net/results/53db871fe076ad96cdb7aecd3930a8
> 6092b9833f/
>          arc |                  empty-0.6.19b | NOK | http://autobuil
> d.buildroot.net/results/943876e5c65707de11cc5890f1ef62537b92b631/

--------------------->8--------------------
empty.c: In function 'main':
empty.c:202:14: error: storage size of 'semu' isn't known
  union semun semu;
              ^
--------------------->8--------------------

This is because toolchain was built without threads and in case of
uClibc that lead to __UCLIBC_HAS_THREADS__ being undefined, which in
its turn undefines _POSIX_SEMAPHORES which is used in "empty.c":
--------------------->8--------------------
/* semaphores */
#ifdef _POSIX_SEMAPHORES
	#if defined(__linux__) && defined(__GNU_LIBRARY__) &&
!defined(_SEM_SEMUN_UNDEFINED)
		/* union semun is defined by including <sys/sem.h> */
	#else
		union semun {
			int val;
			struct semid_ds *buf;
		#ifdef __SVR4
			ushort_t	*array;
		#endif
		#ifdef __hpux__
			ushort		*array;
		#endif
		#ifdef __linux__
			unsigned short *array;
			struct seminfo *__buf;		/* buffer for
IPC_INFO */
		#endif
		};
  	#endif
#endif
	union semun semu;
--------------------->8--------------------

I'm not quite sure what's the correct solution here. Probably we may
just remove "#ifdef _POSIX_SEMAPHORES". That allowed me to compile that
package.

Any thoughts?

>          arc |                    eudev-3.1.1 | NOK | 
> http://autobuild.buildroot.net/results/76ea39dfd70329e2da1e8dcc288f2e
> b3f6715b7b/

--------------------->8--------------------
/home/buildroot/build/instance-0/output/build/eudev
-3.1.1/src/shared/util.c:84: undefined reference to '.tdata'
--------------------->8--------------------

Looks like an issue in our tools, filed internal STAR 9000922620
against it.

>          arc |                  lvm2-2.02.121 | NOK | 
> http://autobuild.buildroot.net/results/0fbf372e874e41162f5d6dc6974478
> 46b51c26c1/

Fixed with http://git.buildroot.net/buildroot/commit/?id=5c51fed1ff2e7a
b66900fa26732ea63dbf148462

>          arc |                    tor-0.2.6.9 | NOK | 
> http://autobuild.buildroot.net/results/ea08eeae05f79598809692a4f9a4ec
> fdd64a63af/

Fixed with http://git.buildroot.net/buildroot/commit/package/tor?id=495
65a282ad6a9f6f04a184407ce04f9c4772e9c

But with mentioned patch I see another build failure:
--------------------->8--------------------
src/common/address.c: In function 'tor_addr_parse_PTR_name':
src/common/address.c:502:5: error: 'for' loop initial declarations are
only allowed in C99 mode
     for (int i = 0; i < 16; ++i) {
     ^
src/common/address.c:502:5: note: use option -std=c99 or -std=gnu99 to
compile your code
--------------------->8--------------------

Fixed with http://git.buildroot.net/buildroot/commit/?id=5cf5b390385fb6
325485e37dc9d38e1e3ac1f091

>          arc |                   zeromq-4.0.5 | NOK | 
> http://autobuild.buildroot.net/results/ff2144e21abb048b0c86ac382b0883
> 0b96999122/

Known "cfi row mismatch [-Werror]". Will be fixed in RC2.

-Alexey

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Thomas Petazzoni]

Dear Alexey Brodkin,

I don't know if your mailer allows that, but if you could avoid
wrapping the text you are replying to, it would be great. Because
you're wrapping the quoted text, all URLs to build reports are broken.

On Mon, 6 Jul 2015 14:51:18 +0000, Alexey Brodkin wrote:


> >          arc |              berkeleydb-5.3.28 | NOK | http://autobuil
> > d.buildroot.net/results/717f3b37600a56262badc6f7cb64d7949fdacb67/
> >          arc |              berkeleydb-5.3.28 | NOK | 
> > http://autobuild.buildroot.net/results/80ebf0382992b277fd94743815bbf0
> > c7426a3654/

[...]

> Fixed with http://patchwork.ozlabs.org/patch/491656/

ACK, applied.

> >          arc |       binutils-arc-2015.06-rc1 | NOK | 
> > http://autobuild.buildroot.net/results/53d333850a82f71c4e708926d35190
> > 93282a6cdf/
> 
> I was not able to reproduce that one and from build log I may assume
> build process was terminated from outside ("ld terminated with signal 6
> [Aborted]"). Is there a chance that build server was shut down or
> something?

Probably not: that build server has an uptime of 215 days. And if a
sudden shutdown happens, the build result is simply lost and never
reported.

However, this machine does have quite a few scary messages in "dmesg",
so if the problem hasn't reproduced another time, I'd say just forget
about it.

> >          arc |                  empty-0.6.19b | NOK | 
> > http://autobuild.buildroot.net/results/53db871fe076ad96cdb7aecd3930a8
> > 6092b9833f/
> >          arc |                  empty-0.6.19b | NOK | http://autobuil
> > d.buildroot.net/results/943876e5c65707de11cc5890f1ef62537b92b631/
> 
> --------------------->8--------------------
> empty.c: In function 'main':
> empty.c:202:14: error: storage size of 'semu' isn't known
>   union semun semu;
>               ^
> --------------------->8--------------------
> 
> This is because toolchain was built without threads and in case of
> uClibc that lead to __UCLIBC_HAS_THREADS__ being undefined, which in
> its turn undefines _POSIX_SEMAPHORES which is used in "empty.c":
> --------------------->8--------------------
> /* semaphores */
> #ifdef _POSIX_SEMAPHORES
> 	#if defined(__linux__) && defined(__GNU_LIBRARY__) &&
> !defined(_SEM_SEMUN_UNDEFINED)
> 		/* union semun is defined by including <sys/sem.h> */
> 	#else
> 		union semun {
> 			int val;
> 			struct semid_ds *buf;
> 		#ifdef __SVR4
> 			ushort_t	*array;
> 		#endif
> 		#ifdef __hpux__
> 			ushort		*array;
> 		#endif
> 		#ifdef __linux__
> 			unsigned short *array;
> 			struct seminfo *__buf;		/* buffer for
> IPC_INFO */
> 		#endif
> 		};
>   	#endif
> #endif
> 	union semun semu;
> --------------------->8--------------------
> 
> I'm not quite sure what's the correct solution here. Probably we may
> just remove "#ifdef _POSIX_SEMAPHORES". That allowed me to compile that
> package.
> 
> Any thoughts?

You could make the package just depend on thread support. *But* it does
build fine with the toolchain at
http://autobuild.buildroot.org/toolchains/configs/br-arm-full-nothread.config.
So it is a little bit weird.

Can you investigate by testing with this prebuilt ARM nothread
toolchain?

Thanks for the analysis of all those ARC build reports!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Alexey Brodkin]

On Mon, 2015-07-06 at 17:43 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> I don't know if your mailer allows that, but if you could avoid
> wrapping the text you are replying to, it would be great. Because
> you're wrapping the quoted text, all URLs to build reports are broken.

Well I used to use Evolution with auto-wrapping on 72 character.
Now I relaxed this limitation to much higher value. Let's see how it goes.

> > >          arc |       binutils-arc-2015.06-rc1 | NOK | 
> > > http://autobuild.buildroot.net/results/53d333850a82f71c4e708926d35190
> > > 93282a6cdf/
> > 
> > I was not able to reproduce that one and from build log I may assume
> > build process was terminated from outside ("ld terminated with signal 6
> > [Aborted]"). Is there a chance that build server was shut down or
> > something?
> 
> Probably not: that build server has an uptime of 215 days. And if a
> sudden shutdown happens, the build result is simply lost and never
> reported.
> 
> However, this machine does have quite a few scary messages in "dmesg",
> so if the problem hasn't reproduced another time, I'd say just forget
> about it.

Let's see indeed it it manifests again.
Probably I was not able to reproduce it because I'm on latest Fedora 22,
while your build machine is something else.

BTW I think we discussed it already - if there's a way to find out details of
a particular build machine? At least it's Linux distro flavor and version.
Preferably output of "gcc -v" and maybe other common tools.

That will allow to reconstruct exactly the same build environment. Remember
we saw a problem with binutils and gdb building that was not reproducible
on Fedora 21/22 but happened on your build machines? 

> > >          arc |                  empty-0.6.19b | NOK | 
> > > http://autobuild.buildroot.net/results/53db871fe076ad96cdb7aecd3930a8
> > > 6092b9833f/
> > >          arc |                  empty-0.6.19b | NOK | http://autobuil
> > > d.buildroot.net/results/943876e5c65707de11cc5890f1ef62537b92b631/
> > 
> > 
> You could make the package just depend on thread support. *But* it does
> build fine with the toolchain at
> http://autobuild.buildroot.org/toolchains/configs/br-arm-full-nothread.config.
> So it is a little bit weird.
> 
> Can you investigate by testing with this prebuilt ARM nothread
> toolchain?

Hm, once again it's probably my different build environment but I have
exactly the same failure with this pre-built ARM toolchain.

That's my output of "make savedefconfig". Basically it's
http://autobuild.buildroot.org/toolchains/configs/br-arm-full-nothread.config
plus BR2_PACKAGE_EMPTY=y:
------------------------------->8----------------------------
BR2_arm=y
BR2_arm1176jzf_s=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="
http://autobuild.buildroot.org/toolchains/tarballs/br-arm11-full-nothread-2015.05-496-g85945aa.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_1=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_EMPTY=y
------------------------------->8----------------------------

And here's what I see while building "empty":
------------------------------->8----------------------------
>>> empty 0.6.19b Extracting
gzip -d -c /home/abrodkin/Projects/sources/git/buildroot/dl/empty-0.6.19b.tgz | tar --strip-components=1 -C
/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/build/empty-0.6.19b  -xf -
>>> empty 0.6.19b Patching

Applying 0001-respect-LDFLAGS.patch using patch: 
patching file Makefile
>>> empty 0.6.19b Configuring
>>> empty 0.6.19b Building
/usr/bin/make -j5 PATH="/home/abrodkin/Outputs/buildroot/empty-arm
-nothreads/host/bin:/home/abrodkin/Outputs/buildroot/empty-arm
-nothreads/host/sbin:/home/abrodkin/Outputs/buildroot/empty-arm
-nothreads/host/usr/bin:/home/abrodkin/Outputs/buildroot/empty-arm
-nothreads/host/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/abrodkin/.local/bin:/home/ab
rodkin/bin:/home/abrodkin/Tools/arc/gnu/2015.06-rc1-uclibc-archs/bin" AR="/home/abrodkin/Outputs/buildroot/empty-arm
-nothreads/host/usr/bin/arm-linux-ar" AS="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux
-as" LD="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-ld"
NM="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-nm"
CC="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-gcc"
GCC="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-gcc"
CPP="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-cpp"
CXX="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-g++"
FC="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-gfortran"
RANLIB="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-ranlib"
READELF="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-readelf"
STRIP="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-strip"
OBJCOPY="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-objcopy"
OBJDUMP="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-objdump" AR_FOR_BUILD="/usr/bin/ar"
AS_FOR_BUILD="/usr/bin/as" CC_FOR_BUILD="/usr/lib64/ccache/gcc" GCC_FOR_BUILD="/usr/lib64/ccache/gcc"
CXX_FOR_BUILD="/usr/lib64/ccache/g++" LD_FOR_BUILD="/usr/bin/ld" CPPFLAGS_FOR_BUILD="
-I/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/include" CFLAGS_FOR_BUILD="-O2 
-I/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/include" CXXFLAGS_FOR_BUILD="-O2 
-I/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/include" LDFLAGS_FOR_BUILD="
-L/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/lib -L/home/abrodkin/Outputs/buildroot/empty-arm
-nothreads/host/usr/lib -Wl,-rpath,/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/lib"
FCFLAGS_FOR_BUILD="" DEFAULT_ASSEMBLER="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-as"
DEFAULT_LINKER="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-ld" CPPFLAGS="
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
-D_FILE_OFFSET_BITS=64   -Os " CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os "
LDFLAGS="" FCFLAGS="" PKG_CONFIG="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/pkg-config"
STAGING_DIR="/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot"
INTLTOOL_PERL=/usr/bin/perl -C /home/abrodkin/Outputs/buildroot/empty-arm-nothreads/build/empty-0.6.19b all
/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/host/usr/bin/arm-linux-gcc -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os   empty.c -lutil -o empty
empty.c: In function ?main?:
empty.c:202:14: error: storage size of ?semu? isn?t known
  union semun semu;
              ^
Makefile:19: recipe for target 'all' failed
make[2]: *** [all] Error 1
package/pkg-generic.mk:156: recipe for target '/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/build/empty
-0.6.19b/.stamp_built' failed
make[1]: *** [/home/abrodkin/Outputs/buildroot/empty-arm-nothreads/build/empty-0.6.19b/.stamp_built] Error 2
Makefile:16: recipe for target '_all' failed
make: *** [_all] Error 2
------------------------------->8----------------------------

-Alexey

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Thomas Petazzoni]

Alexey,

On Wed, 8 Jul 2015 12:15:26 +0000, Alexey Brodkin wrote:

> > I don't know if your mailer allows that, but if you could avoid
> > wrapping the text you are replying to, it would be great. Because
> > you're wrapping the quoted text, all URLs to build reports are broken.
> 
> Well I used to use Evolution with auto-wrapping on 72 character.
> Now I relaxed this limitation to much higher value. Let's see how it goes.

It's actually more complicated than that. You generally need to wrap
the text you write when it's normal text, but not wrap text that is
code example, log files, etc.

> BTW I think we discussed it already - if there's a way to find out details of
> a particular build machine? At least it's Linux distro flavor and version.
> Preferably output of "gcc -v" and maybe other common tools.
> 
> That will allow to reconstruct exactly the same build environment. Remember
> we saw a problem with binutils and gdb building that was not reproducible
> on Fedora 21/22 but happened on your build machines? 

Would be useful. Can you define the exact commands for which you would
like to see the output saved as a description of the "environment"?
Then I could add then to autobuild-run so that they are generated for
each build and pushed as part of the build result to
http://autobuild.buildroot.org.


> Hm, once again it's probably my different build environment but I have
> exactly the same failure with this pre-built ARM toolchain.

No, the difference is that we didn't use the same configuration.

> That's my output of "make savedefconfig". Basically it's
> http://autobuild.buildroot.org/toolchains/configs/br-arm-full-nothread.config
> plus BR2_PACKAGE_EMPTY=y:
> ------------------------------->8----------------------------
> BR2_arm=y
> BR2_arm1176jzf_s=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
> BR2_TOOLCHAIN_EXTERNAL_URL="
> http://autobuild.buildroot.org/toolchains/tarballs/br-arm11-full-nothread-2015.05-496-g85945aa.tar.bz2"
> BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_1=y
> BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
> # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS is not set
> BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> BR2_PACKAGE_EMPTY=y
> ------------------------------->8----------------------------

I have changed
http://autobuild.buildroot.org/toolchains/configs/br-arm-full-nothread.config
just yesterday. You're using the new version, I was using the previous
version. Try again with this defconfig, and you will see the build
succeed:

BR2_arm=y
BR2_arm1176jzf_s=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm11-full-nothread-2015.05.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_0=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_EMPTY=y

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Alexey Brodkin]

On Wed, 2015-07-08 at 14:29 +0200, Thomas Petazzoni wrote:
> I have changed
> http://autobuild.buildroot.org/toolchains/configs/br-arm-full-nothread.config
> just yesterday. You're using the new version, I was using the previous
> version. Try again with this defconfig, and you will see the build
> succeed:
> 
> BR2_arm=y
> BR2_arm1176jzf_s=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm11-full-nothread-2015.05.tar.bz2"
> BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_0=y
> BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
> # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS is not set
> BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> BR2_PACKAGE_EMPTY=y

Ok I now see the difference.

[1] Toolchain that builds "empty" successfully is based on uClibc-0.9.33.2
which simply doesn't have "uClibc_posix_opt.h" where _POSIX_SEMAPHORES
is undefed in more recent versions of uClibc be it uClibc-ng or up to date uClibc
(tip of upstream uClibc's master branch in case of ARC).

See commit that happened 1 month after 0.9.33.2 was cut:
http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/bits/uClibc_posix_opt.h?id=2389017f787dd51e11e697c448071ec
dd217169a

In that commit "uClibc_posix_opt.h" was introduced and since then "empty"
won't built without threads.

Mystery solved? :)

-Alexey

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Thomas Petazzoni]

Dear Alexey Brodkin,

On Wed, 8 Jul 2015 14:33:36 +0000, Alexey Brodkin wrote:

> Ok I now see the difference.
> 
> [1] Toolchain that builds "empty" successfully is based on uClibc-0.9.33.2
> which simply doesn't have "uClibc_posix_opt.h" where _POSIX_SEMAPHORES
> is undefed in more recent versions of uClibc be it uClibc-ng or up to date uClibc
> (tip of upstream uClibc's master branch in case of ARC).
> 
> See commit that happened 1 month after 0.9.33.2 was cut:
> http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/bits/uClibc_posix_opt.h?id=2389017f787dd51e11e697c448071ec
> dd217169a
> 
> In that commit "uClibc_posix_opt.h" was introduced and since then "empty"
> won't built without threads.
> 
> Mystery solved? :)

Thanks for the investigation!

To conclude, I think marking the empty package as not available when
thread support is not there is probably the easiest/simplest solution.
What do you think?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Alexey Brodkin]

Hi Thomas,

On Wed, 2015-07-08 at 16:36 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Wed, 8 Jul 2015 14:33:36 +0000, Alexey Brodkin wrote:
> 
> > Ok I now see the difference.
> > 
> > [1] Toolchain that builds "empty" successfully is based on uClibc-0.9.33.2
> > which simply doesn't have "uClibc_posix_opt.h" where _POSIX_SEMAPHORES
> > is undefed in more recent versions of uClibc be it uClibc-ng or up to date uClibc
> > (tip of upstream uClibc's master branch in case of ARC).
> > 
> > See commit that happened 1 month after 0.9.33.2 was cut:
> > http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/bits/uClibc_posix_opt.h?id=2389017f787dd51e11e697c4480
> > 71ec
> > dd217169a
> > 
> > In that commit "uClibc_posix_opt.h" was introduced and since then "empty"
> > won't built without threads.
> > 
> > Mystery solved? :)
> 
> Thanks for the investigation!
> 
> To conclude, I think marking the empty package as not available when
> thread support is not there is probably the easiest/simplest solution.
> What do you think?

I'd agree with that point, i.e. making "empty" dependent on threads support in toolchain
is the simplest approach for us.

But what bothers me a little bit I am frankly not completely sure if "empty" really needs
threads. Actually it forks a brand new process instead of creating new (p)thread.

And then semaphores are used for IPC between processes.

So if uClibc requires pthread library for implementation of semaphores, then "empty"
is really dependent on threads. And from the first glance I'd say that's the case.

Otherwise we may simply patch "empty".

Adding Waldemar who might comment on that.

-Alexey

[Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28

[Waldemar Brodkorb]

Hi Alexey,
Alexey Brodkin wrote,

> Hi Thomas,
> 
> On Wed, 2015-07-08 at 16:36 +0200, Thomas Petazzoni wrote:
> > Dear Alexey Brodkin,
> > 
> > On Wed, 8 Jul 2015 14:33:36 +0000, Alexey Brodkin wrote:
> > 
> > > Ok I now see the difference.
> > > 
> > > [1] Toolchain that builds "empty" successfully is based on uClibc-0.9.33.2
> > > which simply doesn't have "uClibc_posix_opt.h" where _POSIX_SEMAPHORES
> > > is undefed in more recent versions of uClibc be it uClibc-ng or up to date uClibc
> > > (tip of upstream uClibc's master branch in case of ARC).
> > > 
> > > See commit that happened 1 month after 0.9.33.2 was cut:
> > > http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/bits/uClibc_posix_opt.h?id=2389017f787dd51e11e697c4480
> > > 71ec
> > > dd217169a
> > > 
> > > In that commit "uClibc_posix_opt.h" was introduced and since then "empty"
> > > won't built without threads.
> > > 
> > > Mystery solved? :)
> > 
> > Thanks for the investigation!
> > 
> > To conclude, I think marking the empty package as not available when
> > thread support is not there is probably the easiest/simplest solution.
> > What do you think?
> 
> I'd agree with that point, i.e. making "empty" dependent on threads support in toolchain
> is the simplest approach for us.

But this would be wrong.
 
> But what bothers me a little bit I am frankly not completely sure if "empty" really needs
> threads. Actually it forks a brand new process instead of creating new (p)thread.
> 
> And then semaphores are used for IPC between processes.
> 
> So if uClibc requires pthread library for implementation of semaphores, then "empty"
> is really dependent on threads. And from the first glance I'd say that's the case.
> 
> Otherwise we may simply patch "empty".
> 
> Adding Waldemar who might comment on that.

There are two implementations of semaphores in uClibc. POSIX and
SysV. "empty" just uses SysV and does not depend on threads.

I verified this with a testbuild of "empty" with threads disabled in
uClibc.

So the problem lies in empty.c, because the ifdef _POSIX_SEMAPHORES
is wrong. I am preparing a patch for the package.

best regards
 Waldemar