Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 1/2] package.snappy: fix static builds
@ 2016-10-01 19:04 Yann E. MORIN
  2016-10-01 19:04 ` [Buildroot] [PATCH 2/2] package/snappy: bump version Yann E. MORIN
  2016-10-02 19:19 ` [Buildroot] [PATCH 1/2] package.snappy: fix static builds Peter Korsgaard
  0 siblings, 2 replies; 6+ messages in thread
From: Yann E. MORIN @ 2016-10-01 19:04 UTC (permalink / raw)
  To: buildroot

For some toolchains, libstdc++ uses pthread symbols:

    .../lib/libstdc++.a(eh_alloc.o): In function `__gnu_cxx::__mutex::lock()':
    eh_alloc.cc:(.text._ZN9__gnu_cxx7__mutex4lockEv[_ZN9__gnu_cxx7__mutex4lockEv]+0x2):
    undefined reference to `pthread_mutex_lock'

and a lot of other pthread symbols...

However, when doing a static build, there is no way for the linker what
library to link in, so the build fails miserably if -pthread is not
specified at link time.

Fixes:
    http://autobuild.buildroot.org/results/15e/15ecaa23f0116e8120b3d62e553c838f0303df35/
    http://autobuild.buildroot.org/results/f0a/f0abe301816e39eb4ae26d3e8cd42d90901d5ac5/

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

---
Note: snappy's buildsystem uses libtool, and libsnappy.la does have the
necessary -pthread listed as a "dependency":

   16 # Linker flags that cannot go in dependency_libs.
   17 inherited_linker_flags=' -pthread'

But that is not picked-up by libtool, and I don't know why...
---
 package/snappy/snappy.mk | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/package/snappy/snappy.mk b/package/snappy/snappy.mk
index b00dddf..3e8d603 100644
--- a/package/snappy/snappy.mk
+++ b/package/snappy/snappy.mk
@@ -16,4 +16,12 @@ SNAPPY_INSTALL_STAGING = YES
 # Disable tests
 SNAPPY_CONF_OPTS = --disable-gtest
 
+# libsnappy links with libstdc++. libstdc++ uses pthread symbols. libstdc++
+# does not have a .pc file, and its .la file does not mention -pthread.
+# So, static links to libstdc++ will fail if -pthread is not explicity
+# linked to. Only do that for static builds.
+ifeq ($(BR2_STATIC_LIBS),y)
+SNAPPY_CONF_OPTS += LIBS=-pthread
+endif
+
 $(eval $(autotools-package))
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* [Buildroot] [PATCH 2/2] package/snappy: bump version
  2016-10-01 19:04 [Buildroot] [PATCH 1/2] package.snappy: fix static builds Yann E. MORIN
@ 2016-10-01 19:04 ` Yann E. MORIN
  2016-10-02 19:31   ` Peter Korsgaard
  2016-10-02 19:19 ` [Buildroot] [PATCH 1/2] package.snappy: fix static builds Peter Korsgaard
  1 sibling, 1 reply; 6+ messages in thread
From: Yann E. MORIN @ 2016-10-01 19:04 UTC (permalink / raw)
  To: buildroot

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 package/snappy/snappy.hash | 2 +-
 package/snappy/snappy.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/snappy/snappy.hash b/package/snappy/snappy.hash
index fc979ae..bb7f104 100644
--- a/package/snappy/snappy.hash
+++ b/package/snappy/snappy.hash
@@ -1,2 +1,2 @@
 # Locally calculated
-sha256 d64e434e2ddfe9ae942708747003d489e27f2bfddaa5e9e070da98cb00f660f2  snappy-1ff9be9b8fafc8528ca9e055646f5932aa5db9c4.tar.gz
+sha256 f50719c6dc7103d65df66882a3b4569d598eda251266463eca716928187dc12b  snappy-32d6d7d8a2ef328a2ee1dd40f072e21f4983ebda.tar.gz
diff --git a/package/snappy/snappy.mk b/package/snappy/snappy.mk
index 3e8d603..f491f03 100644
--- a/package/snappy/snappy.mk
+++ b/package/snappy/snappy.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-SNAPPY_VERSION = 1ff9be9b8fafc8528ca9e055646f5932aa5db9c4
+SNAPPY_VERSION = 32d6d7d8a2ef328a2ee1dd40f072e21f4983ebda
 SNAPPY_SITE = $(call github,google,snappy,$(SNAPPY_VERSION))
 SNAPPY_LICENSE = BSD-3c
 SNAPPY_LICENSE_FILES = COPYING
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* [Buildroot] [PATCH 1/2] package.snappy: fix static builds
  2016-10-01 19:04 [Buildroot] [PATCH 1/2] package.snappy: fix static builds Yann E. MORIN
  2016-10-01 19:04 ` [Buildroot] [PATCH 2/2] package/snappy: bump version Yann E. MORIN
@ 2016-10-02 19:19 ` Peter Korsgaard
  1 sibling, 0 replies; 6+ messages in thread
From: Peter Korsgaard @ 2016-10-02 19:19 UTC (permalink / raw)
  To: buildroot

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > For some toolchains, libstdc++ uses pthread symbols:
 >     .../lib/libstdc++.a(eh_alloc.o): In function `__gnu_cxx::__mutex::lock()':
 >     eh_alloc.cc:(.text._ZN9__gnu_cxx7__mutex4lockEv[_ZN9__gnu_cxx7__mutex4lockEv]+0x2):
 >     undefined reference to `pthread_mutex_lock'

 > and a lot of other pthread symbols...

 > However, when doing a static build, there is no way for the linker what
 > library to link in, so the build fails miserably if -pthread is not
 > specified at link time.

 > Fixes:
 >     http://autobuild.buildroot.org/results/15e/15ecaa23f0116e8120b3d62e553c838f0303df35/
 >     http://autobuild.buildroot.org/results/f0a/f0abe301816e39eb4ae26d3e8cd42d90901d5ac5/

 > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

 > ---
 > Note: snappy's buildsystem uses libtool, and libsnappy.la does have the
 > necessary -pthread listed as a "dependency":

 >    16 # Linker flags that cannot go in dependency_libs.
 >    17 inherited_linker_flags=' -pthread'

 > But that is not picked-up by libtool, and I don't know why...

This is arguably a toolchain bug and the thing that fails to link is
just a unit test, so we could also disable it - But OK.

> ---
 >  package/snappy/snappy.mk | 8 ++++++++
 >  1 file changed, 8 insertions(+)

 > diff --git a/package/snappy/snappy.mk b/package/snappy/snappy.mk
 > index b00dddf..3e8d603 100644
 > --- a/package/snappy/snappy.mk
 > +++ b/package/snappy/snappy.mk
 > @@ -16,4 +16,12 @@ SNAPPY_INSTALL_STAGING = YES
 >  # Disable tests
 >  SNAPPY_CONF_OPTS = --disable-gtest
 
 > +# libsnappy links with libstdc++. libstdc++ uses pthread symbols. libstdc++
 > +# does not have a .pc file, and its .la file does not mention -pthread.
 > +# So, static links to libstdc++ will fail if -pthread is not explicity
 > +# linked to. Only do that for static builds.
 > +ifeq ($(BR2_STATIC_LIBS),y)
 > +SNAPPY_CONF_OPTS += LIBS=-pthread
 > +endif

Snappy doesn't depend on threads, so this should only be done if
BR2_TOOLCHAIN_HAS_THREADS.

Committed with that fixed, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [PATCH 2/2] package/snappy: bump version
  2016-10-01 19:04 ` [Buildroot] [PATCH 2/2] package/snappy: bump version Yann E. MORIN
@ 2016-10-02 19:31   ` Peter Korsgaard
  2016-10-02 19:44     ` Yann E. MORIN
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Korsgaard @ 2016-10-02 19:31 UTC (permalink / raw)
  To: buildroot

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

For these bump-to-another-git-revision changes I would prefer some
context / details. For bumps to a new release we at least know that the
maintainer thinks the sw is ready to be used. With random git versions
not so much.

E.G. has some important bugfix or new feature been added? Have you used
it yourself? Is the new hash the latest commit in the repo or something
else? ..

Anyway - Committed, thanks.

> ---
 >  package/snappy/snappy.hash | 2 +-
 >  package/snappy/snappy.mk   | 2 +-
 >  2 files changed, 2 insertions(+), 2 deletions(-)

 > diff --git a/package/snappy/snappy.hash b/package/snappy/snappy.hash
 > index fc979ae..bb7f104 100644
 > --- a/package/snappy/snappy.hash
 > +++ b/package/snappy/snappy.hash
 > @@ -1,2 +1,2 @@
 >  # Locally calculated
 > -sha256
 > d64e434e2ddfe9ae942708747003d489e27f2bfddaa5e9e070da98cb00f660f2
 > snappy-1ff9be9b8fafc8528ca9e055646f5932aa5db9c4.tar.gz
 > +sha256
 > f50719c6dc7103d65df66882a3b4569d598eda251266463eca716928187dc12b
 > snappy-32d6d7d8a2ef328a2ee1dd40f072e21f4983ebda.tar.gz
 > diff --git a/package/snappy/snappy.mk b/package/snappy/snappy.mk
 > index 3e8d603..f491f03 100644
 > --- a/package/snappy/snappy.mk
 > +++ b/package/snappy/snappy.mk
 > @@ -4,7 +4,7 @@
 >  #
 >  ################################################################################
 
 > -SNAPPY_VERSION = 1ff9be9b8fafc8528ca9e055646f5932aa5db9c4
 > +SNAPPY_VERSION = 32d6d7d8a2ef328a2ee1dd40f072e21f4983ebda
 >  SNAPPY_SITE = $(call github,google,snappy,$(SNAPPY_VERSION))
 >  SNAPPY_LICENSE = BSD-3c
 >  SNAPPY_LICENSE_FILES = COPYING
 > -- 
 > 2.7.4

 > _______________________________________________
 > buildroot mailing list
 > buildroot at busybox.net
 > http://lists.busybox.net/mailman/listinfo/buildroot


-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [PATCH 2/2] package/snappy: bump version
  2016-10-02 19:31   ` Peter Korsgaard
@ 2016-10-02 19:44     ` Yann E. MORIN
  2016-10-02 19:52       ` Peter Korsgaard
  0 siblings, 1 reply; 6+ messages in thread
From: Yann E. MORIN @ 2016-10-02 19:44 UTC (permalink / raw)
  To: buildroot

Peter, All,

On 2016-10-02 21:31 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> For these bump-to-another-git-revision changes I would prefer some
> context / details. For bumps to a new release we at least know that the
> maintainer thinks the sw is ready to be used. With random git versions
> not so much.
> 
> E.G. has some important bugfix or new feature been added? Have you used
> it yourself? Is the new hash the latest commit in the repo or something
> else? ..

Here's your commit log:

There's been a single release of snappy since the move from GoogleCode
to Github; that release was more than a year ago. In that time frame,
only 14 commits went in master, of which to merges, so about 1 real
commit per month...

For a brief summary of additional stuff since the last release:
  - provide snappy.pc
  - a few generic bug fixes, as well as a few ARM-specific ones
  - a few buildsystem fixes

Since we can't say releases are made on a timely cadence, let's just hop
to the latest master from the git tree.

;-)

> Anyway - Committed, thanks.

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.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Buildroot] [PATCH 2/2] package/snappy: bump version
  2016-10-02 19:44     ` Yann E. MORIN
@ 2016-10-02 19:52       ` Peter Korsgaard
  0 siblings, 0 replies; 6+ messages in thread
From: Peter Korsgaard @ 2016-10-02 19:52 UTC (permalink / raw)
  To: buildroot

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Peter, All,
 > On 2016-10-02 21:31 +0200, Peter Korsgaard spake thusly:
 >> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
 >> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 >> 
 >> For these bump-to-another-git-revision changes I would prefer some
 >> context / details. For bumps to a new release we at least know that the
 >> maintainer thinks the sw is ready to be used. With random git versions
 >> not so much.
 >> 
 >> E.G. has some important bugfix or new feature been added? Have you used
 >> it yourself? Is the new hash the latest commit in the repo or something
 >> else? ..

 > Here's your commit log:

 > There's been a single release of snappy since the move from GoogleCode
 > to Github; that release was more than a year ago. In that time frame,
 > only 14 commits went in master, of which to merges, so about 1 real
 > commit per month...

 > For a brief summary of additional stuff since the last release:
 >   - provide snappy.pc
 >   - a few generic bug fixes, as well as a few ARM-specific ones
 >   - a few buildsystem fixes

 > Since we can't say releases are made on a timely cadence, let's just hop
 > to the latest master from the git tree.

Great, please add this kind of info to the commit message next time, at
least the .pc file could be interesting.

-- 
Venlig hilsen,
Peter Korsgaard 

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-02 19:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-01 19:04 [Buildroot] [PATCH 1/2] package.snappy: fix static builds Yann E. MORIN
2016-10-01 19:04 ` [Buildroot] [PATCH 2/2] package/snappy: bump version Yann E. MORIN
2016-10-02 19:31   ` Peter Korsgaard
2016-10-02 19:44     ` Yann E. MORIN
2016-10-02 19:52       ` Peter Korsgaard
2016-10-02 19:19 ` [Buildroot] [PATCH 1/2] package.snappy: fix static builds Peter Korsgaard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox