fix-build-when-std-gnu99-and-inline-functions-are-used
cover fix-build-when-std-gnu99-and-inline-functions-are-used
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.
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(+)
Signature · 1 line
2.5.0
PATCH 1/2 host-tar: fix build when -std=gnu99 and inline functions are used
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.
--- package/tar/tar.mk | 1 + 1 file changed, 1 insertion(+)
package/tar/tar.mk +1 -0
@@ -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) && \
Signature · 1 line
2.5.0
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
In reply to Lada TrimasovaA 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.
--- package/m4/m4.mk | 1 + 1 file changed, 1 insertion(+)
package/m4/m4.mk +1 -0
@@ -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))
Signature · 1 line
2.5.0
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Dear Lada Trimasova,
Quoted 6 lines · 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.
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?
package/m4/m4.mk M4_SITE = $(BR2_GNU_MIRROR)/m4 · line 13
Quoted 9 lines
package/m4/m4.mk +1
-0@@ -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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
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?
package/m4/m4.mk +1 -0
@@ -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
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Hello,
Quoted 1 line · Lada Trimasova
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Hi Thomas,
Quoted 7 lines · Thomas Petazzoni
Hello,
Quoted 1 line · Lada Trimasova
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.
Quoted 2 lines
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
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Quoted 8 lines · Alexey Brodkin
Hi Thomas,
Quoted 5 lines · Thomas Petazzoni
Hello,
Quoted 1 line · Lada Trimasova
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]
Quoted 2 lines
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.
Quoted 3 lines
And now I think we may even consider adding it
to the top-levelHOST_CFLAGSinstead 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
Quoted 15 lines
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
Signature · 6 lines
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
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Hi Arnout,
Quoted 8 lines · Arnout Vandecappelle
Quoted 7 lines · Alexey Brodkin
Hi Thomas,
Quoted 4 lines · Thomas Petazzoni
Hello,
On Thu, 25 Feb 2016 12:58:05 +0000, Lada Trimasova wrote:
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
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]
Quoted 2 lines
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.
Quoted 11 lines
Quoted 3 lines
And now I think we may even consider adding it
to the top-levelHOST_CFLAGSinstead 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
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Hello,
Quoted 10 lines · Alexey Brodkin
Quoted 2 lines
?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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/2 host-m4: fix build when -std=gnu99 and inline functions are used
Hi Thomas,
Quoted 15 lines · Thomas Petazzoni
Hello,
Quoted 10 lines · Alexey Brodkin
Quoted 2 lines
?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.
Quoted 6 lines
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