[Buildroot] [PATCH 0/2] fix-build-when-std-gnu99-and-inline-functions-are-used

[Buildroot] [PATCH 0/2] fix-build-when-std-gnu99-and-inline-functions-are-used

[Lada Trimasova]

A lot of the glibc header files use extern inline, which causes
GCC to emit a symbol for each extern inline functions and it causes
functions multiple definition error when "-std=gnu99" is used.
To fix this problem it's necessary to use "-fgnu89-inline" option, which
tells GCC to use the traditional GNU semantics for inline functions when
in C99 mode.

Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>

Lada Trimasova (2):
  host-tar: fix build when -std=gnu99 and inline functions are used
  host-m4: fix build when -std=gnu99 and inline functions are used

 package/m4/m4.mk   | 1 +
 package/tar/tar.mk | 1 +
 2 files changed, 2 insertions(+)

-- 
2.5.0

[Buildroot] [PATCH 1/2] host-tar: fix build when -std=gnu99 and inline functions are used

[Lada Trimasova]

A lot of the glibc header files use extern inline, which causes
GCC to emit a symbol for each extern inline functions and it causes
functions multiple definition error when "-std=gnu99" is used.
To fix this problem it's necessary to use "-fgnu89-inline" option, which
tells GCC to use the traditional GNU semantics for inline functions when
in C99 mode.

Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
---
 package/tar/tar.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/tar/tar.mk b/package/tar/tar.mk
index 2b47e33..e59aedb 100644
--- a/package/tar/tar.mk
+++ b/package/tar/tar.mk
@@ -38,6 +38,7 @@ $(eval $(autotools-package))
 # host-tar: use cpio.gz instead of tar.gz to prevent chicken-egg problem
 # of needing tar to build tar.
 HOST_TAR_SOURCE = tar-$(TAR_VERSION).cpio.gz
+HOST_TAR_MAKE_OPTS = CFLAGS="-fgnu89-inline"
 define HOST_TAR_EXTRACT_CMDS
 	mkdir -p $(@D)
 	cd $(@D) && \
-- 
2.5.0

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Lada Trimasova]

A lot of the glibc header files use extern inline, which causes
GCC to emit a symbol for each extern inline functions and it causes
functions multiple definition error when "-std=gnu99" is used.
To fix this problem it's necessary to use "-fgnu89-inline" option which
tells GCC to use the traditional GNU semantics for inline functions when
in C99 mode.

Signed-off-by: Lada Trimasova <ltrimas@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
---
 package/m4/m4.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/m4/m4.mk b/package/m4/m4.mk
index 9b5d2d1..2644bb1 100644
--- a/package/m4/m4.mk
+++ b/package/m4/m4.mk
@@ -10,5 +10,6 @@ M4_SITE = $(BR2_GNU_MIRROR)/m4
 M4_LICENSE = GPLv3+
 M4_LICENSE_FILES = COPYING
 HOST_M4_CONF_OPTS = --disable-static
+HOST_M4_MAKE_OPTS = CFLAGS="-fgnu89-inline"
 
 $(eval $(host-autotools-package))
-- 
2.5.0

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Thomas Petazzoni]

Dear Lada Trimasova,

On Thu, 25 Feb 2016 14:37:10 +0300, Lada Trimasova wrote:
> A lot of the glibc header files use extern inline, which causes
> GCC to emit a symbol for each extern inline functions and it causes
> functions multiple definition error when "-std=gnu99" is used.
> To fix this problem it's necessary to use "-fgnu89-inline" option which
> tells GCC to use the traditional GNU semantics for inline functions when
> in C99 mode.

I'm using gcc 5.x on my laptop, which I believe defaults to -std=gnu99,
and host-m4 builds fine for me. Could you describe more precisely in
which cases host-m4 doesn't build for you?

> diff --git a/package/m4/m4.mk b/package/m4/m4.mk
> index 9b5d2d1..2644bb1 100644
> --- a/package/m4/m4.mk
> +++ b/package/m4/m4.mk
> @@ -10,5 +10,6 @@ M4_SITE = $(BR2_GNU_MIRROR)/m4
>  M4_LICENSE = GPLv3+
>  M4_LICENSE_FILES = COPYING
>  HOST_M4_CONF_OPTS = --disable-static
> +HOST_M4_MAKE_OPTS = CFLAGS="-fgnu89-inline"

I think it's cleaner to pass this in the configure script environment,
i.e:

HOST_M4_CONF_ENV = \
	CFLAGS="$(HOST_CFLAGS) -fgnu89-inline"

(Same comments for the host-tar patch).

Thanks,

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

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Lada Trimasova]

Hi Thomas,

I used CentOS 5.7, gcc 4.9.2, glibc 2.5.

Regards,
Lada
On Thu, 2016-02-25 at 13:54 +0100, Thomas Petazzoni wrote:

Dear Lada Trimasova,

On Thu, 25 Feb 2016 14:37:10 +0300, Lada Trimasova wrote:


A lot of the glibc header files use extern inline, which causes
GCC to emit a symbol for each extern inline functions and it causes
functions multiple definition error when "-std=gnu99" is used.
To fix this problem it's necessary to use "-fgnu89-inline" option which
tells GCC to use the traditional GNU semantics for inline functions when
in C99 mode.



I'm using gcc 5.x on my laptop, which I believe defaults to -std=gnu99,
and host-m4 builds fine for me. Could you describe more precisely in
which cases host-m4 doesn't build for you?



diff --git a/package/m4/m4.mk b/package/m4/m4.mk
index 9b5d2d1..2644bb1 100644
--- a/package/m4/m4.mk
+++ b/package/m4/m4.mk
@@ -10,5 +10,6 @@ M4_SITE = $(BR2_GNU_MIRROR)/m4
 M4_LICENSE = GPLv3+
 M4_LICENSE_FILES = COPYING
 HOST_M4_CONF_OPTS = --disable-static
+HOST_M4_MAKE_OPTS = CFLAGS="-fgnu89-inline"



I think it's cleaner to pass this in the configure script environment,
i.e:

HOST_M4_CONF_ENV = \
        CFLAGS="$(HOST_CFLAGS) -fgnu89-inline"

(Same comments for the host-tar patch).

Thanks,

Thomas

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Thomas Petazzoni]

Hello,

On Thu, 25 Feb 2016 12:58:05 +0000, Lada Trimasova wrote:

> I used CentOS 5.7, gcc 4.9.2, glibc 2.5.

Are you talking about gcc 4.9 for the target or gcc 4.9 for the host ?

It seems weird to be using such a recent gcc version with such an
ancient glibc version.

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

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Alexey Brodkin]

Hi Thomas,

On Thu, 2016-02-25 at 14:26 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 25 Feb 2016 12:58:05 +0000, Lada Trimasova wrote:
> 
> > I used CentOS 5.7, gcc 4.9.2, glibc 2.5.
> 
> Are you talking about gcc 4.9 for the target or gcc 4.9 for the host ?

Definitely we're talking about host gcc.

> It seems weird to be using such a recent gcc version with such an
> ancient glibc version.

Indeed. On our corporate farm machines we may select different tools
versions and on that particular machine that runs RedHat 5.7 we had an
option to use gcc 4.9 (the latest from available options).

But there's no way to change glibc version (really how can we change
it right beneath our feet) and glibc is really 2.5:
------------>8------------
$ ldd --version
ldd (GNU libc) 2.5
------------>8------------

And indeed on our dev machines that are up to date Fedora 23
we don't see any issues with building host-tar or m4.

So that's what happens in details:

[1] In our olde good glibc-2.5 if FORTIFY_SOURCE is defined by user
? ? (and tar does so) following implementation of ptsname_r() from
? ? /usr/include/bits/stdlib.h is used:
------------>8------------
extern __always_inline int
__NTH (ptsname_r (int __fd, char *__buf, size_t __buflen))
{
? if (__bos (__buf) != (size_t) -1
??????&& (!__builtin_constant_p (__buflen) || __buflen > __bos (__buf)))
????return __ptsname_r_chk (__fd, __buf, __buflen, __bos (__buf));
? return __ptsname_r_alias (__fd, __buf, __buflen);
}
------------>8------------

[2] Back in the day of glibc-2.5 C89 inline semantics were used, which
? ? were:
------------>8------------
...
If you specify both inline and extern in the function definition,
then the definition is used only for inlining.
------------>8------------

[3] In later inline semantics like in C99 if there's no "static"
? ? then compiler assumes this is global symbol.

That's why with older host glibc we need to pass "-fgnu89-inline"
flag to compiler. And now I think we may even consider adding it
to the top-level HOST_CFLAGS instead of fixing problem on per-package
basis.

Any thoughts?

And indeed we now have to determine last glibc version that relies on
C89 inline semantics.

-Alexey

P.S. Just in case that article was of great help:
http://stackoverflow.com/questions/2722276/multiple-definition-of-inline-function

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Arnout Vandecappelle]

On 02/25/16 16:33, Alexey Brodkin wrote:
> Hi Thomas,
> 
> On Thu, 2016-02-25 at 14:26 +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Thu, 25 Feb 2016 12:58:05 +0000, Lada Trimasova wrote:
>>
>>> I used CentOS 5.7, gcc 4.9.2, glibc 2.5.
[snip explanation of why this combination of gcc 4.9 with glibc 2.5 is broken]
> That's why with older host glibc we need to pass "-fgnu89-inline"
> flag to compiler.

 I think you can basically say your host toolchain is broken: it fails to
compile valid programs, because glibc doesn't satisfy the -std=gnu99 option.

> And now I think we may even consider adding it
> to the top-level HOST_CFLAGS instead of fixing problem on per-package
> basis.

 Since this is an issue with your toolchain, I think you should fix it globally
(not just for buildroot) by setting CFLAGS_FOR_BUILD=-fgnu89-inline in your
environment.


 Note: installing your own glibc (somewhere outside of /usr/lib) is possible,
but awkward.

 Regards,
 Arnout

> 
> Any thoughts?
> 
> And indeed we now have to determine last glibc version that relies on
> C89 inline semantics.
> 
> -Alexey
> 
> P.S. Just in case that article was of great help:
> http://stackoverflow.com/questions/2722276/multiple-definition-of-inline-function
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Alexey Brodkin]

Hi Arnout,

On Thu, 2016-02-25 at 23:13 +0100, Arnout Vandecappelle wrote:
> On 02/25/16 16:33, Alexey Brodkin wrote:
> > Hi Thomas,
> > 
> > On Thu, 2016-02-25 at 14:26 +0100, Thomas Petazzoni wrote:
> > > Hello,
> > > 
> > > On Thu, 25 Feb 2016 12:58:05 +0000, Lada Trimasova wrote:
> > > 
> > > > I used CentOS 5.7, gcc 4.9.2, glibc 2.5.
> [snip explanation of why this combination of gcc 4.9 with glibc 2.5 is broken]
> > That's why with older host glibc we need to pass "-fgnu89-inline"
> > flag to compiler.
> 
> ?I think you can basically say your host toolchain is broken: it fails to
> compile valid programs, because glibc doesn't satisfy the -std=gnu99 option.

That's very true. But it looks like on RedHat/CentOS 5.x (which are still
in use here and there) discussed problem exists.

Given default gcc in RHEL 5 is 4.1 (though 3.4 and 4.4 are available via
compat-gcc-34 and gcc44 correspondingly) ad it fails to compile host tar and m4
in current Buildroot I would still look for a permanent solution in vanilla
Buildroot instead of work-around on per machine basis.

> > And now I think we may even consider adding it
> > to the top-level HOST_CFLAGS instead of fixing problem on per-package
> > basis.
> 
> ?Since this is an issue with your toolchain, I think you should fix it globally
> (not just for buildroot) by setting CFLAGS_FOR_BUILD=-fgnu89-inline in your
> environment.
> 
> 
> ?Note: installing your own glibc (somewhere outside of /usr/lib) is possible,
> but awkward.

Indeed almost all is doable but we're talking here about "true enterprise"
approach when user has no admin privileges and what's more may have no
knowledge about stuff he uses. That's why I'd like to make sure Buildroot
just works on almost all sane setups today.

-Alexey

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Thomas Petazzoni]

Hello,

On Fri, 26 Feb 2016 07:20:24 +0000, Alexey Brodkin wrote:

> > ?I think you can basically say your host toolchain is broken: it fails to
> > compile valid programs, because glibc doesn't satisfy the -std=gnu99 option.
> 
> That's very true. But it looks like on RedHat/CentOS 5.x (which are still
> in use here and there) discussed problem exists.
> 
> Given default gcc in RHEL 5 is 4.1 (though 3.4 and 4.4 are available via
> compat-gcc-34 and gcc44 correspondingly) ad it fails to compile host tar and m4
> in current Buildroot I would still look for a permanent solution in vanilla
> Buildroot instead of work-around on per machine basis.

With the default gcc 4.1 used in RHEL5, I would assume that glibc 2.5
works fine and that you can use Buildroot with no problem. Have you
tried building Buildroot with the default gcc 4.1 ?

What Arnout calls a broken toolchain is your combination of gcc 4.9 and
glibc 2.5.

If you want Buildroot to work on platform where there is no working
native toolchain, the only solution is to bundle Buildroot with a
chroot environment, and ask users to build inside the chroot. Probably
not something we want to do.

Best regards,

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

[Buildroot] [PATCH 2/2] host-m4: fix build when -std=gnu99 and inline functions are used

[Alexey Brodkin]

Hi Thomas,

On Fri, 2016-02-26 at 09:19 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 26 Feb 2016 07:20:24 +0000, Alexey Brodkin wrote:
> 
> > > ?I think you can basically say your host toolchain is broken: it fails to
> > > compile valid programs, because glibc doesn't satisfy the -std=gnu99 option.
> > 
> > That's very true. But it looks like on RedHat/CentOS 5.x (which are still
> > in use here and there) discussed problem exists.
> > 
> > Given default gcc in RHEL 5 is 4.1 (though 3.4 and 4.4 are available via
> > compat-gcc-34 and gcc44 correspondingly) ad it fails to compile host tar and m4
> > in current Buildroot I would still look for a permanent solution in vanilla
> > Buildroot instead of work-around on per machine basis.
> 
> With the default gcc 4.1 used in RHEL5, I would assume that glibc 2.5
> works fine and that you can use Buildroot with no problem. Have you
> tried building Buildroot with the default gcc 4.1 ?
> 
> What Arnout calls a broken toolchain is your combination of gcc 4.9 and
> glibc 2.5.

Ok so finally I made one good experiment - built Buildroot from scratch
with gcc 4.1 and you know what - it was built perfectly fine.

So I think what we first did was a real misuse - I hope lesson will be
learned - it's risky to use shiny new stuff on ages old machines :)

I.e. both patches could be dropped now and I'll make sure people
uses correct combo of tools on our farm machines.

And sorry for that noise!

-Alexey