[1/1] protobuf/protobuf-c: bump versions

From: Nimai Mahajan <nimaim@gmail.com>

Signed-off-by: Nimai Mahajan <nimaim@gmail.com>
---
 package/protobuf-c/protobuf-c.mk | 2 +-
 package/protobuf/protobuf.mk     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Nimai, All,

On 2015-08-13 21:41 -0400, Nimai Mahajan spake thusly:
> From: Nimai Mahajan <nimaim@gmail.com>
> 
> Signed-off-by: Nimai Mahajan <nimaim@gmail.com>
> ---
>  package/protobuf-c/protobuf-c.mk | 2 +-
>  package/protobuf/protobuf.mk     | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/protobuf-c/protobuf-c.mk b/package/protobuf-c/protobuf-c.mk
> index d73eb25..ee4500e 100644
> --- a/package/protobuf-c/protobuf-c.mk
> +++ b/package/protobuf-c/protobuf-c.mk
> @@ -4,7 +4,7 @@
>  #
>  ################################################################################
>  
> -PROTOBUF_C_VERSION = v1.0.0-rc1
> +PROTOBUF_C_VERSION = v1.1.1
>  PROTOBUF_C_SITE = $(call github,protobuf-c,protobuf-c,$(PROTOBUF_C_VERSION))
>  PROTOBUF_C_DEPENDENCIES = host-protobuf-c
>  HOST_PROTOBUF_C_DEPENDENCIES = host-protobuf host-pkgconf
> diff --git a/package/protobuf/protobuf.mk b/package/protobuf/protobuf.mk
> index 0426fce..144e5fb 100644
> --- a/package/protobuf/protobuf.mk
> +++ b/package/protobuf/protobuf.mk
> @@ -4,7 +4,7 @@
>  #
>  ################################################################################
>  
> -PROTOBUF_VERSION = v2.5.0
> +PROTOBUF_VERSION = v2.6.1

Last time we tried to bump protobuf to v2.6.0, we got a lot of build
failures, so the bump was reverted;
    http://git.buildroot.org/buildroot/commit/?id=7b6304af9d69d44ee3040c00b0670f19c02de7d2
    http://git.buildroot.org/buildroot/commit/?id=61ae22810a8ca90d3b904d89eb3892c6cf92e87c

Did you test under various conditions, such as:
  - static-only  (2.5.0 currently fails in this case, I'm lookimng into it)
  - the various supported architectures: arm, i386, mipsel, x86_64
  - with various C libraries: uClibc, musl, glibc

If you did, then good! :-)

Otherwise, I'd like this bump to at least be tested in the musl and
static-only scenario (to see if that improves the situation...)

Also, it seems v2.6.x adds proper support for PowerPC.

Thanks! :-)

Regards,
Yann E. MORIN.

>  PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION))
>  PROTOBUF_LICENSE = BSD-3c
>  PROTOBUF_LICENSE_FILES = COPYING.txt
> -- 
> 1.9.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

On Fri, Aug 14, 2015 at 8:19 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Nimai, All,
>
> On 2015-08-13 21:41 -0400, Nimai Mahajan spake thusly:
>> From: Nimai Mahajan <nimaim@gmail.com>
>>
>> Signed-off-by: Nimai Mahajan <nimaim@gmail.com>
>> ---
>>  package/protobuf-c/protobuf-c.mk | 2 +-
>>  package/protobuf/protobuf.mk     | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/protobuf-c/protobuf-c.mk b/package/protobuf-c/protobuf-c.mk
>> index d73eb25..ee4500e 100644
>> --- a/package/protobuf-c/protobuf-c.mk
>> +++ b/package/protobuf-c/protobuf-c.mk
>> @@ -4,7 +4,7 @@
>>  #
>>  ################################################################################
>>
>> -PROTOBUF_C_VERSION = v1.0.0-rc1
>> +PROTOBUF_C_VERSION = v1.1.1
>>  PROTOBUF_C_SITE = $(call github,protobuf-c,protobuf-c,$(PROTOBUF_C_VERSION))
>>  PROTOBUF_C_DEPENDENCIES = host-protobuf-c
>>  HOST_PROTOBUF_C_DEPENDENCIES = host-protobuf host-pkgconf
>> diff --git a/package/protobuf/protobuf.mk b/package/protobuf/protobuf.mk
>> index 0426fce..144e5fb 100644
>> --- a/package/protobuf/protobuf.mk
>> +++ b/package/protobuf/protobuf.mk
>> @@ -4,7 +4,7 @@
>>  #
>>  ################################################################################
>>
>> -PROTOBUF_VERSION = v2.5.0
>> +PROTOBUF_VERSION = v2.6.1
>
> Last time we tried to bump protobuf to v2.6.0, we got a lot of build
> failures, so the bump was reverted;
>     http://git.buildroot.org/buildroot/commit/?id=7b6304af9d69d44ee3040c00b0670f19c02de7d2
>     http://git.buildroot.org/buildroot/commit/?id=61ae22810a8ca90d3b904d89eb3892c6cf92e87c

Sorry, I had no idea this was already tried to be pushed up ... I did
try to search for this but gmane doesn't make that very easy.

>
> Did you test under various conditions, such as:
>   - static-only  (2.5.0 currently fails in this case, I'm lookimng into it)
>   - the various supported architectures: arm, i386, mipsel, x86_64
>   - with various C libraries: uClibc, musl, glibc
>
> If you did, then good! :-)

Bah no I did not :-( I only tested with arm and i386 and glibc as I
have toolchains for these both. I would love to set up an environment
where I can test all these combinations more easily before pushing
something up ... what would be your recommendation for doing that?

>
> Otherwise, I'd like this bump to at least be tested in the musl and
> static-only scenario (to see if that improves the situation...)
>
> Also, it seems v2.6.x adds proper support for PowerPC.

Yes, 2.6.1 also fixes a bunch of bugs (we use protocol buffers in
production code and can attest to this) so I wanted to get it up there
but needs a lot more testing with getting built with various
configurations first.

I can certainly at least try a musl static build with this.

>
> Thanks! :-)
>
> Regards,
> Yann E. MORIN.
>
>>  PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION))
>>  PROTOBUF_LICENSE = BSD-3c
>>  PROTOBUF_LICENSE_FILES = COPYING.txt
>> --
>> 1.9.1
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

Nimai, All,

On 2015-08-14 08:29 -0400, Nimai Mahajan spake thusly:
> On Fri, Aug 14, 2015 at 8:19 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2015-08-13 21:41 -0400, Nimai Mahajan spake thusly:
[--SNIP--]
> >> diff --git a/package/protobuf/protobuf.mk b/package/protobuf/protobuf.mk
> >> index 0426fce..144e5fb 100644
> >> --- a/package/protobuf/protobuf.mk
> >> +++ b/package/protobuf/protobuf.mk
> >> @@ -4,7 +4,7 @@
> >>  #
> >>  ################################################################################
> >>
> >> -PROTOBUF_VERSION = v2.5.0
> >> +PROTOBUF_VERSION = v2.6.1
> >
> > Last time we tried to bump protobuf to v2.6.0, we got a lot of build
> > failures, so the bump was reverted;
> >     http://git.buildroot.org/buildroot/commit/?id=7b6304af9d69d44ee3040c00b0670f19c02de7d2
> >     http://git.buildroot.org/buildroot/commit/?id=61ae22810a8ca90d3b904d89eb3892c6cf92e87c
> 
> Sorry, I had no idea this was already tried to be pushed up ... I did
> try to search for this but gmane doesn't make that very easy.

No problem! I only knew about the revert because I was investigating the
static build faiulures, and also considered the bump... ;-)

> > Did you test under various conditions, such as:
> >   - static-only  (2.5.0 currently fails in this case, I'm lookimng into it)
> >   - the various supported architectures: arm, i386, mipsel, x86_64
> >   - with various C libraries: uClibc, musl, glibc
> >
> > If you did, then good! :-)
> 
> Bah no I did not :-( I only tested with arm and i386 and glibc as I
> have toolchains for these both. I would love to set up an environment
> where I can test all these combinations more easily before pushing
> something up ... what would be your recommendation for doing that?

You can start with any of those defconfig:

    static based on uClibc:
    http://autobuild.buildroot.org/toolchains/configs/br-arm-full-static.config

    based on musl (but need to manually set static):
    http://autobuild.buildroot.org/toolchains/configs/br-arm-cortex-a9-musl.config

Save them locally, and run:

    make BR2_DEFCONFIG=/path/to/where/you/saved/br-arm-full-static.config defconfig
    make menuconfig
        -- enable protobuf
        -- exit
    make protobuf

(Similarly for the musl build, but you need to enable static-only in the
menuconfig).

> > Otherwise, I'd like this bump to at least be tested in the musl and
> > static-only scenario (to see if that improves the situation...)
> >
> > Also, it seems v2.6.x adds proper support for PowerPC.
> 
> Yes, 2.6.1 also fixes a bunch of bugs (we use protocol buffers in
> production code and can attest to this) so I wanted to get it up there
> but needs a lot more testing with getting built with various
> configurations first.
> 
> I can certainly at least try a musl static build with this.

OK, great! Thanks! :-)

Regards,
Yann E. MORIN.

On Fri, Aug 14, 2015 at 8:37 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Nimai, All,
>
> On 2015-08-14 08:29 -0400, Nimai Mahajan spake thusly:
>> On Fri, Aug 14, 2015 at 8:19 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> > On 2015-08-13 21:41 -0400, Nimai Mahajan spake thusly:
> [--SNIP--]
>> >> diff --git a/package/protobuf/protobuf.mk b/package/protobuf/protobuf.mk
>> >> index 0426fce..144e5fb 100644
>> >> --- a/package/protobuf/protobuf.mk
>> >> +++ b/package/protobuf/protobuf.mk
>> >> @@ -4,7 +4,7 @@
>> >>  #
>> >>  ################################################################################
>> >>
>> >> -PROTOBUF_VERSION = v2.5.0
>> >> +PROTOBUF_VERSION = v2.6.1
>> >
>> > Last time we tried to bump protobuf to v2.6.0, we got a lot of build
>> > failures, so the bump was reverted;
>> >     http://git.buildroot.org/buildroot/commit/?id=7b6304af9d69d44ee3040c00b0670f19c02de7d2
>> >     http://git.buildroot.org/buildroot/commit/?id=61ae22810a8ca90d3b904d89eb3892c6cf92e87c
>>
>> Sorry, I had no idea this was already tried to be pushed up ... I did
>> try to search for this but gmane doesn't make that very easy.
>
> No problem! I only knew about the revert because I was investigating the
> static build faiulures, and also considered the bump... ;-)
>
>> > Did you test under various conditions, such as:
>> >   - static-only  (2.5.0 currently fails in this case, I'm lookimng into it)
>> >   - the various supported architectures: arm, i386, mipsel, x86_64
>> >   - with various C libraries: uClibc, musl, glibc
>> >
>> > If you did, then good! :-)
>>
>> Bah no I did not :-( I only tested with arm and i386 and glibc as I
>> have toolchains for these both. I would love to set up an environment
>> where I can test all these combinations more easily before pushing
>> something up ... what would be your recommendation for doing that?
>
> You can start with any of those defconfig:
>
>     static based on uClibc:
>     http://autobuild.buildroot.org/toolchains/configs/br-arm-full-static.config
>
>     based on musl (but need to manually set static):
>     http://autobuild.buildroot.org/toolchains/configs/br-arm-cortex-a9-musl.config
>
> Save them locally, and run:
>
>     make BR2_DEFCONFIG=/path/to/where/you/saved/br-arm-full-static.config defconfig
>     make menuconfig
>         -- enable protobuf
>         -- exit
>     make protobuf
>
> (Similarly for the musl build, but you need to enable static-only in the
> menuconfig).
>

Thanks for the suggestion! I didn't know autobuilder had prebuilt
external toolchains for anyone to use publicly; sure saves loads of
time :-) Just tested the toolchains you suggested (musl static and
uClibc static) in addition to the ones I normally test (i386 + arm
glibc shared libs) and these are the results:

protobuf-c v1.1.1 builds successfully with all toolchains ...
protobuf    v2.6.1 builds successfully with everything except uClibc
static, where it fails with this:

D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c
google/protobuf/stubs/atomicops_internals_x86_gcc.cc -o
google/protobuf/stubs/atomicops_internals_x86_gcc.o
google/protobuf/stubs/common.cc:48:2: error: #error "No suitable
threading library available."
 #error "No suitable threading library available."
  ^
/bin/bash ../libtool  --tag=CXX   --mode=compile
/home/nimai/Desktop/buildroot/buildroot/output/host/usr/bin/arm-linux-g++
-DHAVE_CONFIG_H -I. -I..   -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pthread -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os  -static -static -c
-o google/protobuf/stubs/stringprintf.lo
google/protobuf/stubs/stringprintf.cc
/bin/bash ../libtool  --tag=CXX   --mode=compile
/home/nimai/Desktop/buildroot/buildroot/output/host/usr/bin/arm-linux-g++
-DHAVE_CONFIG_H -I. -I..   -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pthread -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os  -static -static -c
-o google/protobuf/extension_set.lo google/protobuf/extension_set.cc
/bin/bash ../libtool  --tag=CXX   --mode=compile
/home/nimai/Desktop/buildroot/buildroot/output/host/usr/bin/arm-linux-g++
-DHAVE_CONFIG_H -I. -I..   -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pthread -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os  -static -static -c
-o google/protobuf/generated_message_util.lo
google/protobuf/generated_message_util.cc
/bin/bash ../libtool  --tag=CXX   --mode=compile
/home/nimai/Desktop/buildroot/buildroot/output/host/usr/bin/arm-linux-g++
-DHAVE_CONFIG_H -I. -I..   -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pthread -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os  -static -static -c
-o google/protobuf/message_lite.lo google/protobuf/message_lite.cc
libtool: compile:
/home/nimai/Desktop/buildroot/buildroot/output/host/usr/bin/arm-linux-g++
-DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pthread -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c
google/protobuf/stubs/stringprintf.cc -o
google/protobuf/stubs/stringprintf.o
libtool: compile:
/home/nimai/Desktop/buildroot/buildroot/output/host/usr/bin/arm-linux-g++
-DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pthread -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c
google/protobuf/extension_set.cc -o google/protobuf/extension_set.o
make[4]: *** [google/protobuf/stubs/common.lo] Error 1

Seems to be a threading library issue but toolchain has NPTL thread
support I believe so not sure why that is.

>> > Otherwise, I'd like this bump to at least be tested in the musl and
>> > static-only scenario (to see if that improves the situation...)
>> >
>> > Also, it seems v2.6.x adds proper support for PowerPC.
>>
>> Yes, 2.6.1 also fixes a bunch of bugs (we use protocol buffers in
>> production code and can attest to this) so I wanted to get it up there
>> but needs a lot more testing with getting built with various
>> configurations first.
>>
>> I can certainly at least try a musl static build with this.
>
> OK, great! Thanks! :-)
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

Nimai, All,

On 2015-08-14 11:11 -0400, Nimai Mahajan spake thusly:
> On Fri, Aug 14, 2015 at 8:37 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> >     http://autobuild.buildroot.org/toolchains/configs/br-arm-full-static.config
> >     http://autobuild.buildroot.org/toolchains/configs/br-arm-cortex-a9-musl.config
[--SNIP--]
> Thanks for the suggestion! I didn't know autobuilder had prebuilt
> external toolchains for anyone to use publicly;

Yes, it is a little-known fact. Even I often forgets about it from time
to time... :-/

> protobuf-c v1.1.1 builds successfully with all toolchains ...

Good. Please provide a separate patch just to bump protobuf-c, then.

> protobuf    v2.6.1 builds successfully with everything except uClibc
> static, where it fails with this:
> 
> D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c
> google/protobuf/stubs/atomicops_internals_x86_gcc.cc -o
> google/protobuf/stubs/atomicops_internals_x86_gcc.o
> google/protobuf/stubs/common.cc:48:2: error: #error "No suitable
> threading library available."
>  #error "No suitable threading library available."
>   ^
[--SNIP--]
> Seems to be a threading library issue but toolchain has NPTL thread
> support I believe so not sure why that is.

In fact, it is not a threading issue. If you look closely at the
config.log, you'll see that pthreads are properly detected, but that a
further check about shared libs is broken, see:

    http://autobuild.buildroot.org/results/3ef/3efb86c7e8ec2db5d953d634470cafae79bd34cf/protobuf-v2.5.0/config.log

Most notably:

    checking for the pthreads library -lpthreads... no
    checking whether pthreads work without any flags... no
    checking whether pthreads work with -Kthread... no
    checking whether pthreads work with -kthread... no
    checking for the pthreads library -llthread... no
    checking whether pthreads work with -pthread... yes
    checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
    checking if more special flags are required for pthreads... no
    checking whether to check for GCC pthread/shared inconsistencies... yes
    checking whether -pthread is sufficient with -shared... no
    checking whether -lpthread fixes that... no
    checking whether -lc_r fixes that... no
    configure: WARNING: Impossible to determine how to use pthreads with shared libraries
    checking whether what we have so far is sufficient with -nostdlib... no
    checking whether -lpthread saves the day... no
    configure: WARNING: Impossible to determine how to use pthreads with shared libraries and -nostdlib

So, it's those checks about "GCC pthread/shared inconsistencies" that
are broken: it forcibly tries a shared link, even thoug h we are asking
for static link.

It all happens in an m4 macro, in protobuf-v2.5.0/m4/acx_pthread.m4,
around lines 239..375.

Fixing this macros is a huge "enterntainment" ;-]

So I think it is musch easier to just mark the package as not being
availble for static-only builds...

Regards,
Yann E. MORIN.

On Aug 14, 2015 11:42 AM, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>
> Nimai, All,
>
> On 2015-08-14 11:11 -0400, Nimai Mahajan spake thusly:
> > On Fri, Aug 14, 2015 at 8:37 AM, Yann E. MORIN <yann.morin.1998@free.fr>
wrote:
> [--SNIP--]
> > >
http://autobuild.buildroot.org/toolchains/configs/br-arm-full-static.config
> > >
http://autobuild.buildroot.org/toolchains/configs/br-arm-cortex-a9-musl.config
> [--SNIP--]
> > Thanks for the suggestion! I didn't know autobuilder had prebuilt
> > external toolchains for anyone to use publicly;
>
> Yes, it is a little-known fact. Even I often forgets about it from time
> to time... :-/
>
> > protobuf-c v1.1.1 builds successfully with all toolchains ...
>
> Good. Please provide a separate patch just to bump protobuf-c, then.

Yep, will do.

>
> > protobuf    v2.6.1 builds successfully with everything except uClibc
> > static, where it fails with this:
> >
> > D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c
> > google/protobuf/stubs/atomicops_internals_x86_gcc.cc -o
> > google/protobuf/stubs/atomicops_internals_x86_gcc.o
> > google/protobuf/stubs/common.cc:48:2: error: #error "No suitable
> > threading library available."
> >  #error "No suitable threading library available."
> >   ^
> [--SNIP--]
> > Seems to be a threading library issue but toolchain has NPTL thread
> > support I believe so not sure why that is.
>
> In fact, it is not a threading issue. If you look closely at the
> config.log, you'll see that pthreads are properly detected, but that a
> further check about shared libs is broken, see:
>
>
http://autobuild.buildroot.org/results/3ef/3efb86c7e8ec2db5d953d634470cafae79bd34cf/protobuf-v2.5.0/config.log
>
> Most notably:
>
>     checking for the pthreads library -lpthreads... no
>     checking whether pthreads work without any flags... no
>     checking whether pthreads work with -Kthread... no
>     checking whether pthreads work with -kthread... no
>     checking for the pthreads library -llthread... no
>     checking whether pthreads work with -pthread... yes
>     checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
>     checking if more special flags are required for pthreads... no
>     checking whether to check for GCC pthread/shared inconsistencies...
yes
>     checking whether -pthread is sufficient with -shared... no
>     checking whether -lpthread fixes that... no
>     checking whether -lc_r fixes that... no
>     configure: WARNING: Impossible to determine how to use pthreads with
shared libraries
>     checking whether what we have so far is sufficient with -nostdlib...
no
>     checking whether -lpthread saves the day... no
>     configure: WARNING: Impossible to determine how to use pthreads with
shared libraries and -nostdlib
>
> So, it's those checks about "GCC pthread/shared inconsistencies" that
> are broken: it forcibly tries a shared link, even thoug h we are asking
> for static link.
>
> It all happens in an m4 macro, in protobuf-v2.5.0/m4/acx_pthread.m4,
> around lines 239..375.

Thanks for looking into it Yann. I see it now. So many broken autotools
packages! Add this one to the list.

>
> Fixing this macros is a huge "enterntainment" ;-]
>
> So I think it is musch easier to just mark the package as not being
> availble for static-only builds...

Agreed ... will do. I appreciate the help.

>
> Regards,
> Yann E. MORIN.
>
> --
>
.-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
     |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There
is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
 conspiracy.  |
>
'------------------------------^-------^------------------^--------------------'

Nimai, All,

On 2015-08-14 11:54 -0400, Nimai Mahajan spake thusly:
> On Aug 14, 2015 11:42 AM, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > On 2015-08-14 11:11 -0400, Nimai Mahajan spake thusly:
[--SNIP--]
> > > protobuf-c v1.1.1 builds successfully with all toolchains ...
> > Good. Please provide a separate patch just to bump protobuf-c, then.
> Yep, will do.

Thanks! :-)

[--SNIP--]
> > So I think it is musch easier to just mark the package as not being
> > availble for static-only builds...
> 
> Agreed ... will do. I appreciate the help.

In this case, prepare two patches:
  - one to "fix" the static issue, that can be applied to master,
  - ont to do the bump, which can be applied to the -next branch.

Beware when "fixing" that static issue: two packages do select
BR2_PACKAGE_PROTOBUF (ola and mosh) so the new dependency must be
propagated to those two packages as well.

(In fact I already have the fix locally, but did not have time to submit
it so far, so be my guest and submit it if you want! ;-) )

Regards,
Yann E. MORIN.

Nimai, All,

On 2015-08-14 18:45 +0200, Yann E. MORIN spake thusly:
> On 2015-08-14 11:54 -0400, Nimai Mahajan spake thusly:
> > On Aug 14, 2015 11:42 AM, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > > So I think it is musch easier to just mark the package as not being
> > > availble for static-only builds...
> > Agreed ... will do. I appreciate the help.
> 
> In this case, prepare two patches:
>   - one to "fix" the static issue, that can be applied to master,
[--SNIP--]
> (In fact I already have the fix locally, but did not have time to submit
> it so far, so be my guest and submit it if you want! ;-) )

So, I've now sent this patch:
    https://patchwork.ozlabs.org/patch/507628/

Regards,
Yann E. MORIN.

On Aug 15, 2015 5:28 AM, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>
> Nimai, All,
>
> On 2015-08-14 18:45 +0200, Yann E. MORIN spake thusly:
> > On 2015-08-14 11:54 -0400, Nimai Mahajan spake thusly:
> > > On Aug 14, 2015 11:42 AM, "Yann E. MORIN" <yann.morin.1998@free.fr>
wrote:
> > > > So I think it is musch easier to just mark the package as not being
> > > > availble for static-only builds...
> > > Agreed ... will do. I appreciate the help.
> >
> > In this case, prepare two patches:
> >   - one to "fix" the static issue, that can be applied to master,
> [--SNIP--]
> > (In fact I already have the fix locally, but did not have time to submit
> > it so far, so be my guest and submit it if you want! ;-) )
>
> So, I've now sent this patch:
>     https://patchwork.ozlabs.org/patch/507628/
>
> Regards,
> Yann E. MORIN.

Thank you very much Yann. I got tied up in some things and was going to
take care of this next week but seems you best me to it :-)

>
> --
>
.-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
     |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There
is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
 conspiracy.  |
>
'------------------------------^-------^------------------^--------------------'