[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

Morning, all!

I had a look in the archives, but did not find any recent information that  
seems to cover the problems I am experiencing.

About 18 months ago, we had our target build system configured by a  
consultant. This is an Xscale target. We made the root FS fit in the  
allotted space, just fine. Preparing to add a new controller card to our  
product range, I decided to download a fresh Buildroot, then configure to  
match the old setup (which has issues building on Ubuntu 9.04 or later,  
possibly due to some package we have added). Busybox and uclibc config  
files are copied from the previous buildroot environment.

As it turns out, the rootfs of this configuration is several MBs larger  
than the previous one, mainly due to an explosion of shared libraries.

/usr/lib has a lot of glib*.so files that were not previously there, and  
also iconv has been added. In addition, both libstd++.so.6.0.9 and  
libstd++.so.6.0.10 are added. /usr/lib is now twice the size of that of  
the previous target, meaning it won't fit on the target anymore. I believe  
glib* are parts of GLIBC, how come it is installed when I am trying to  
build a uclibc system?

I tried to prune the rootfs a bit to match the old target rootfs, but  
after that NO applications built with the buildroot toolchain works. All  
system utils work perfectly, but nothing I have written works. All apps,  
whether a small simple C app or a large C++ app, die with a Segmentation  
fault immediately, before reaching main(). GDB/GDBserver is not useful for  
telling where the problem lies.


If anyone would like to help investigate the problem, I can send my  
configuration files to you to see if you are able to recreate the  
behaviour.

-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Sven Neumann]

On Fri, 2009-11-06 at 08:47 +0100, Joachim Pihl wrote:

> I had a look in the archives, but did not find any recent information that  
> seems to cover the problems I am experiencing.
> 
> About 18 months ago, we had our target build system configured by a  
> consultant. This is an Xscale target. We made the root FS fit in the  
> allotted space, just fine. Preparing to add a new controller card to our  
> product range, I decided to download a fresh Buildroot, then configure to  
> match the old setup (which has issues building on Ubuntu 9.04 or later,  
> possibly due to some package we have added). Busybox and uclibc config  
> files are copied from the previous buildroot environment.
> 
> As it turns out, the rootfs of this configuration is several MBs larger  
> than the previous one, mainly due to an explosion of shared libraries.
> 
> /usr/lib has a lot of glib*.so files that were not previously there, and  
> also iconv has been added. In addition, both libstd++.so.6.0.9 and  
> libstd++.so.6.0.10 are added. /usr/lib is now twice the size of that of  
> the previous target, meaning it won't fit on the target anymore. I believe  
> glib* are parts of GLIBC, how come it is installed when I am trying to  
> build a uclibc system?

glib is http://library.gnome.org/devel/glib/stable/glib.html and should
not be confused with glibc.

I assume that some package you selected pulled in libglib2, which itself
pulls in other things like iconv. Just check your package selection and
make sure that you only select the packages you absolutely need.


Sven

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 09:52:16 +0100, Sven Neumann <s.neumann@raumfeld.com>  
wrote:

>
> glib is http://library.gnome.org/devel/glib/stable/glib.html and should
> not be confused with glibc.
>
> I assume that some package you selected pulled in libglib2, which itself
> pulls in other things like iconv. Just check your package selection and
> make sure that you only select the packages you absolutely need.


Thanks for clearing that up! I found glib_genmarshal in /usr/bin, but I  
have absolutely no idea of why it has been included. There is no package I  
can find that mentions it. Also, this does not explain the duplicate  
libstdc++ libraries.


Attaching the complete configuration.

-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclibc.config
Type: application/octet-stream
Size: 5923 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091106/34bd791d/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.config
Type: application/octet-stream
Size: 22906 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091106/34bd791d/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multicon.config
Type: application/octet-stream
Size: 19696 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091106/34bd791d/attachment-0005.obj>

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Sven Neumann]

On Fri, 2009-11-06 at 09:59 +0100, Joachim Pihl wrote:

> > glib is http://library.gnome.org/devel/glib/stable/glib.html and should
> > not be confused with glibc.
> >
> > I assume that some package you selected pulled in libglib2, which itself
> > pulls in other things like iconv. Just check your package selection and
> > make sure that you only select the packages you absolutely need.
> 
> 
> Thanks for clearing that up! I found glib_genmarshal in /usr/bin, but I  
> have absolutely no idea of why it has been included. There is no package I  
> can find that mentions it. Also, this does not explain the duplicate  
> libstdc++ libraries.

glib-genmarshal should only be installed in the host directory, not in
the target directory. Are you absolutely sure you are looking at the
right folder?


Sven

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 10:02:24 +0100, Sven Neumann <s.neumann@raumfeld.com>  
wrote:

> glib-genmarshal should only be installed in the host directory, not in
> the target directory. Are you absolutely sure you are looking at the
> right folder?

I am looking inside the rootfs.tar created by running make using the above  
config files. I am positive it is in there.

-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Thomas Petazzoni]

Le Fri, 6 Nov 2009 08:47:16 +0100,
Joachim Pihl <jpihl@nevion.com> a ?crit :

> /usr/lib has a lot of glib*.so files that were not previously there,
> and also iconv has been added. In addition, both libstd++.so.6.0.9
> and libstd++.so.6.0.10 are added. /usr/lib is now twice the size of
> that of the previous target, meaning it won't fit on the target
> anymore. I believe glib* are parts of GLIBC, how come it is installed
> when I am trying to build a uclibc system?

As Sven said, glib is a different thing than glibc. It's a foundation
library of the Gtk stack.

> If anyone would like to help investigate the problem, I can send my  
> configuration files to you to see if you are able to recreate the  
> behaviour.

Please send your .config to the list and describe what are the
dependencies of your own applications.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 10:04:59 +0100, Thomas Petazzoni  
<thomas.petazzoni@free-electrons.com> wrote:

> Please send your .config to the list and describe what are the
> dependencies of your own applications.

All the crashing applications are built _outside_ the buildroot  
environment, using the toolchain created by buildroot. This worked  
perfectly before I started messing with it.

We have added 5 packages to buildroot, none of these have configurational  
dependencies outside themselves. The packages are:

libgd
boost
spread
libsnmppdu
libnetwork


-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Thomas Petazzoni]

Le Fri, 6 Nov 2009 09:59:28 +0100,
Joachim Pihl <jpihl@nevion.com> a ?crit :

> Thanks for clearing that up! I found glib_genmarshal in /usr/bin, but
> I have absolutely no idea of why it has been included. There is no
> package I can find that mentions it. Also, this does not explain the
> duplicate libstdc++ libraries.

Ok, here is the full list of packages you selected:

BR2_PACKAGE_GDB_SERVER=y
BR2_PACKAGE_GDB_HOST=y
BR2_PACKAGE_BUSYBOX=y
BR2_PACKAGE_BUSYBOX_FULLINSTALL=y
BR2_PACKAGE_BUSYBOX_CONFIG="busybox.config"
BR2_PACKAGE_GETTEXT=y
BR2_PACKAGE_GETTEXT_STATIC=y
BR2_PACKAGE_LIBINTL=y
BR2_PACKAGE_PKG_CONFIG=y
BR2_PACKAGE_READLINE=y
BR2_PACKAGE_BOOST=y
BR2_PACKAGE_BOOST_CONFIG_THREADING=y
BR2_PACKAGE_BOOST_DATE_TIME=y
BR2_PACKAGE_BOOST_THREAD=y
BR2_PACKAGE_LIBICONV=y
BR2_PACKAGE_LIBNW=y
BR2_PACKAGE_LIBSNMPPDU=y
BR2_PACKAGE_SPREAD=y
BR2_PACKAGE_SQLITE=y
BR2_PACKAGE_NETSNMP=y
BR2_PACKAGE_NTP=y
BR2_PACKAGE_THTTPD=y
BR2_PACKAGE_VSFTPD=y
BR2_PACKAGE_MTD=y
 [ Lots of MTD stuff ]
BR2_PACKAGE_NCURSES=y
BR2_PACKAGE_LIBGD=y
BR2_PACKAGE_LIBPNG=y
BR2_PACKAGE_LIBGLIB2=y
BR2_PACKAGE_LZO=y
BR2_PACKAGE_ZLIB=y
BR2_PACKAGE_LIBXML2=y

I think you don't need pkg-config on the target, so disable
BR2_PACKAGE_PKG_CONFIG. This should allow you to disable libglib2
(BR2_PACKAGE_LIBGLIB2), which in turn will allow you to disable gettext
(BR2_PACKAGE_GETTEXT), libintl (BR2_PACKAGE_LIBINTL), libiconv
(BR2_PACKAGE_LIBICONV).

Of course, this makes the assumption that your own internal
applications do not use libglib2.

Then, for the Boost packages, then don't exist in Buildroot, so we
can't say what dependencies they pull. Could you submit a patch to add
the Boost libraries into Buildroot ?

Finally, for the duplicated C++ library thing, could you put online
your rootfs.tar (after removing your internal applications if they are
sensitive) ?

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Thomas Petazzoni]

Le Fri, 6 Nov 2009 10:26:52 +0100,
Joachim Pihl <jpihl@nevion.com> a ?crit :

> All the crashing applications are built _outside_ the buildroot  
> environment, using the toolchain created by buildroot. This worked  
> perfectly before I started messing with it.

You cannot expect the system to work after more or less randomly
removing libraries, even if they at first sight look useless.

How do you compile your applications exactly ? (Compiler flags, etc.).

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 10:42:49 +0100, Thomas Petazzoni  
<thomas.petazzoni@free-electrons.com> wrote:

> I think you don't need pkg-config on the target, so disable
> BR2_PACKAGE_PKG_CONFIG. This should allow you to disable libglib2
> (BR2_PACKAGE_LIBGLIB2), which in turn will allow you to disable gettext
> (BR2_PACKAGE_GETTEXT), libintl (BR2_PACKAGE_LIBINTL), libiconv
> (BR2_PACKAGE_LIBICONV).
>
> Of course, this makes the assumption that your own internal
> applications do not use libglib2.

No, they don't, so I will try the above. I think it would well explain the  
library problems.

> Then, for the Boost packages, then don't exist in Buildroot, so we
> can't say what dependencies they pull. Could you submit a patch to add
> the Boost libraries into Buildroot ?

Makefile and config input file attached. We have several patches to make  
it compile on PXA255, I guess I could provide those if you need them.

> Finally, for the duplicated C++ library thing, could you put online
> your rootfs.tar (after removing your internal applications if they are
> sensitive) ?

It seems that is gone from the latest build I attempted. *blush* Can't  
remember what I changed that can have caused that.




-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config.in
Type: application/octet-stream
Size: 3748 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091106/e84d00e3/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boost.mk
Type: application/octet-stream
Size: 5342 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091106/e84d00e3/attachment-0003.obj>

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 10:53:25 +0100, Thomas Petazzoni  
<thomas.petazzoni@free-electrons.com> wrote:

> Le Fri, 6 Nov 2009 10:26:52 +0100,
> Joachim Pihl <jpihl@nevion.com> a ?crit :
>
>> All the crashing applications are built _outside_ the buildroot
>> environment, using the toolchain created by buildroot. This worked
>> perfectly before I started messing with it.
>
> You cannot expect the system to work after more or less randomly
> removing libraries, even if they at first sight look useless.


Got the rootfs down to a manageable size now, but the crashing persists.


> How do you compile your applications exactly ? (Compiler flags, etc.).

Application makefiles are unchanged after buildroot 0.10.

typical C++ compile:
arm-linux-g++ -c -O3 -g3 -DVERSION="\"3.2.0-RC3-svn18398-jpihl\""  
-DBUILD="\"18398\"" -Wall -DBOOST_SP_USE_PTHREADS -DBOOST_AC_USE_PTHREADS  
-DBOOST_HAS_THREADS -o arm-linux/UserFactory.o UserFactory.cpp

typical C compile:
arm-linux-gcc -O3 -Wall -DVERSION=\"3.2.0-RC3-svn18398-jpihl\"  
-DBUILD=\"18398\" -DSERVER_HOST=\"127.0.0.1\" -DSERVER_PORT=5000  
-D__XSCALE__=1 -MMD -MF arm-linux/.deps/alarms_changed.d -c  
alarms_changed.c -o arm-linux/alarms_changed.o


create static library:
arm-linux-ar -r arm-linux/libutil.a arm-linux/Alarm.o  
arm-linux/ClientSocket.o arm-linux/CommandSingleton.o arm-linux/ConfData.o  
arm-linux/CrcSingleton.o arm-linux/Debug.o arm-linux/Features.o  
arm-linux/gpio.o arm-linux/gpio_xscale.o arm-linux/Interface.o  
arm-linux/IPAddr.o arm-linux/KeyManager.o arm-linux/module.o  
arm-linux/Multicast.o arm-linux/SerialInterface.o arm-linux/SerialPort.o  
arm-linux/ServerSocket.o arm-linux/snmp.o arm-linux/SnmpLevel.o  
arm-linux/Socket.o arm-linux/SyncFpga.o arm-linux/TcpClientInterface.o  
arm-linux/TcpServerInterface.o arm-linux/TcpServerListener.o  
arm-linux/tinystr.o arm-linux/tinyxml.o arm-linux/tinyxmlerror.o  
arm-linux/tinyxmlparser.o arm-linux/User.o arm-linux/UserFactory.o  
arm-linux/UserGroup.o arm-linux/get_random.o arm-linux/keys.o  
arm-linux/license.o arm-linux/md5.o

link C++:
arm-linux-g++ -o arm-linux/ClientConverter arm-linux/ClientConverter.o  
arm-linux/MrpClientParser.o  -L ../util/arm-linux -lutil -lboost_thread-mt  
-lboost_date_time-mt -lspread -lcrypt -lsqlite3 -ldl


checking for .so dependencies on host for one of the crashing binaries:

jpihl at x:~/mac_tool/arm-linux$arm-linux-ldd mac_tool
checking sub-depends for '/usr/lib/libboost_thread-mt.so'
checking sub-depends for '/usr/lib/libboost_date_time-mt.so'
checking sub-depends for 'not found'
checking sub-depends for 'not found'
checking sub-depends for '/usr/lib/libsqlite3.so.0'
checking sub-depends for '/usr/lib/libstdc++.so.6'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libgcc_s.so.1'
checking sub-depends for '/lib/libc.so.0'
checking sub-depends for '/lib/librt.so.1'
Segmentation fault


Doesn't look good to me, will revert to previous tool chain to have a look  
at what it says then. In the old buildroot, we had the threads library set  
to linuxthreads, but I have changed that to NPTL. Could that be the  
culprit?


-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 13:16:10 +0100, Joachim Pihl <jpihl@nevion.com> wrote:

> Doesn't look good to me, will revert to previous tool chain to have a  
> look
> at what it says then. In the old buildroot, we had the threads library  
> set
> to linuxthreads, but I have changed that to NPTL. Could that be the
> culprit?

I have narrowed the field a bit. It turns out that applications built and  
linked with gcc work, those built with g++ DO NOT. Must be some library  
issue of sorts.

-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 13:28:54 +0100, Joachim Pihl <jpihl@nevion.com> wrote:

> I have narrowed the field a bit. It turns out that applications built and
> linked with gcc work, those built with g++ DO NOT. Must be some library
> issue of sorts.

I keep answering myself...

Now there is no libpthreads on the target! That would explain a whole lot.  
I have looked through all options in xconfig (I think), is there a key I  
could/should add to the dependencies of boost_threads to make sure it is  
included?


-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Fri, 06 Nov 2009 13:48:13 +0100, Joachim Pihl <jpihl@nevion.com> wrote:

> I keep answering myself...

Yet again...

> Now there is no libpthreads on the target! That would explain a whole  
> lot.
> I have looked through all options in xconfig (I think), is there a key I
> could/should add to the dependencies of boost_threads to make sure it is
> included?

Sorry for the false alarm, looked in the wrong directory. libpthreads is  
of course in /lib, not in /usr/lib.

-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Peter Korsgaard]

>>>>> "Joachim" == Joachim Pihl <jpihl@nevion.com> writes:

 Joachim> On Fri, 06 Nov 2009 10:42:49 +0100, Thomas Petazzoni
 Joachim> <thomas.petazzoni@free-electrons.com> wrote:

 >> I think you don't need pkg-config on the target, so disable
 >> BR2_PACKAGE_PKG_CONFIG. This should allow you to disable libglib2
 >> (BR2_PACKAGE_LIBGLIB2), which in turn will allow you to disable gettext
 >> (BR2_PACKAGE_GETTEXT), libintl (BR2_PACKAGE_LIBINTL), libiconv
 >> (BR2_PACKAGE_LIBICONV).
 >> 
 >> Of course, this makes the assumption that your own internal
 >> applications do not use libglib2.

 Joachim> No, they don't, so I will try the above. I think it would well explain
 Joachim> the  library problems.

Some time ago we renamed the confusing pkgconfig package name, so now
host-pkgconfig is pkgconfig for the host (needed by lots of packages),
and pkgconfig is pkgconfig for the target (normally not needed).

-- 
Bye, Peter Korsgaard

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Peter Korsgaard]

>>>>> "Joachim" == Joachim Pihl <jpihl@nevion.com> writes:

Hi,

 Joachim> Doesn't look good to me, will revert to previous tool chain to
 Joachim> have a look at what it says then. In the old buildroot, we had
 Joachim> the threads library set to linuxthreads, but I have changed
 Joachim> that to NPTL. Could that be the culprit?

Yes, NTPL support in uclibc is still very much work in progress.

-- 
Bye, Peter Korsgaard

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Joachim Pihl]

On Sat, 07 Nov 2009 11:10:19 +0100, Peter Korsgaard <jacmet@uclibc.org>  
wrote:

>>>>>> "Joachim" == Joachim Pihl <jpihl@nevion.com> writes:
>
> Hi,
>
>  Joachim> Doesn't look good to me, will revert to previous tool chain to
>  Joachim> have a look at what it says then. In the old buildroot, we had
>  Joachim> the threads library set to linuxthreads, but I have changed
>  Joachim> that to NPTL. Could that be the culprit?
>
> Yes, NTPL support in uclibc is still very much work in progress.

Just before I left work yesterday, I discovered that the uclibc .config  
(inherited from previous project) had "use linuxthreads" set, while  
buildroot had NPTL set. The mismatch here could be what we are looking for?

I would much prefer NPTL if it works, since our applications are heavily  
multithreaded (for architecture clarity reasons, among other things), and  
I suspect that some of the performance issues we have could be caused by  
context switch/scheduling latency.

-- 
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------

[Buildroot] Upgrading from Buildroot 0.10 to 2009.08 (ARM)

[Peter Korsgaard]

>>>>> "Joachim" == Joachim Pihl <jpihl@nevion.com> writes:

Hi,

 >> Yes, NTPL support in uclibc is still very much work in progress.

 Joachim> Just before I left work yesterday, I discovered that the uclibc
 Joachim> .config  (inherited from previous project) had "use linuxthreads" set,
 Joachim> while  buildroot had NPTL set. The mismatch here could be what we are
 Joachim> looking for?

No, buildroot rewrites that part of the uclibc config (see
toolchain/uClibc/uclibc.mk)

 Joachim> I would much prefer NPTL if it works, since our applications
 Joachim> are heavily multithreaded (for architecture clarity reasons,
 Joachim> among other things), and I suspect that some of the
 Joachim> performance issues we have could be caused by context
 Joachim> switch/scheduling latency.

You should probably check on the uclibc list, but there's afaik no NPTL
support for any architecture in any released uclibc versions.

-- 
Bye, Peter Korsgaard