Fails to inline using gcc-5.x Reproducible: Always Steps to Reproduce: 1.gcc-5x 2. 3. Actual Results: ustr-srch-opt-code.c:(.text+0x940): multiple definition of `ustr_add_cstr' ustr-b-code-so-opt.o:ustr-b-opt-code.c:(.text+0x940): first defined here ustr-srch-code-so-opt.o: In function `ustrp_dupx_cstr': ustr-srch-opt-code.c:(.text+0x9b0): multiple definition of `ustrp_dupx_cstr' ustr-b-code-so-opt.o:ustr-b-opt-code.c:(.text+0x9b0): first defined here ustr-srch-code-so-opt.o: In function `ustrp_dup_cstr': ustr-srch-opt-code.c:(.text+0xa40): multiple definition of `ustrp_dup_cstr' ustr-b-code-so-opt.o:ustr-b-opt-code.c:(.text+0xa40): first defined here ustr-srch-code-so-opt.o: In function `ustr_dupx_cstr': ustr-srch-opt-code.c:(.text+0xab0): multiple definition of `ustr_dupx_cstr' ustr-b-code-so-opt.o:ustr-b-opt-code.c:(.text+0xab0): first defined here ustr-srch-code-so-opt.o: In function `ustr_dup_cstr':
Created attachment 408120 [details, diff] inline patch
I'll look into it in the next few days.
Hi all, sorry for the long delay. It took a lot longer to upgrade my system to gcc-5.2.0 than I expected. And the the perl upgrade to 5.22 gave me quite a busy time. However, I have long debated with myself about how to fix this and came to the following conclusion: The reason for this error is, that the behaviour of the 'inline' keyword changed between C89 and C99. The variant you patched in, Jory, forces the C89 behaviour on a C99 and above build. This is needed, because GCC-5 changes the default from C89 to C99. However, what if someone tries to compile ustr using gcc-5 and sets CFLAGS=-std=c89 ? Patching the change in would make this fail. And I doubt it would work with gcc-4.x either with explicitly setting -std=c99 or above. So my solution is to patch ustr-conf.h.in (used everywhere) to make a preprocessor check itself and defining the inline keyword itself to become the old variant using the gnu_inline __attribute__ if gcc 5+ is used and the c standard is at least c99. The result can be tried out from my overlay 'seden', available via layman. However, I will attach the changed ebuild and the patch here for review and in-tree inclusion.
Created attachment 411488 [details, diff] Add a check against gcc-5 and C99 This patch adds a preprocessor check against the gcc major version and the used C standard version and defines the 'inline' keyword to mimic the old C89 behaviour if gcc 5 with at least C99 are used.
Created attachment 411490 [details] dev-libs/ustr-1.0.4-r6.ebuild Ebuild using the attached patch.
This builds and installs. commit 7dea6f8820f36bf389e6315044bea7507553bed0 Author: Ian Delaney <idella4@gentoo.org> Date: Sun Sep 13 11:14:45 2015 +0800 dev-libs/ustr: revbump; patch and ebuild submitted in bug #556452
Confirmed successful merge from portage tree with ABI_X86_32 and ABI_X86_64 using gcc-5.2.0. As this is now in the tree, this bug is resolved.
(In reply to Sven Eden from comment #7) > Confirmed successful merge from portage tree with ABI_X86_32 and ABI_X86_64 > using gcc-5.2.0. > > As this is now in the tree, this bug is resolved. Actually no. Courtesy of explanation by Arfrever, the ustr-1.0.4-r6.ebuild is badly broken. I missed realising the ustr-1.0.4-r6.ebuild was built on the revbumped ustr-1.0.4-r3 instead of the most recent ustr-1.0.4-r5. The ebuild in fact fails when exposed to ABI_X86="32 64". commit a6538bd29209681140f0e7d5f4844f2513287e5c Author: Ian Delaney <idella4@gentoo.org> Date: Tue Sep 15 14:25:37 2015 +0800 dev-libs/ustr: revbump ustr-1.0.4-r7.ebuild made from base of ustr-1.0.4-r5.ebuild with changes from Bug #556452 correcting patch submitted by user which added changes to the stabled ustr-1.0.4-r5 as the base, removed the brokenustr-1.0.4-r6 ebuild, ack to Arfrever for reporting and providing support to make ustr-1.0.4-r7.
(In reply to Ian Delaney from comment #8) > The ebuild in fact fails when exposed to ABI_X86="32 64". I'd like to learn why it built (and worked) just fine on my machine, then. If it failed here I'd noticed... So, what did I miss? Apart from taking the wrong ebuild as a base, of course.
Not sure you can seek out and ask Arfrever but I suspect you might be missing FEATURES="multilib-strict in make.conf
