Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 556452 - dev-libs/ustr gcc-5.x porting
Summary: dev-libs/ustr gcc-5.x porting
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sven Eden
Depends on:
Blocks: gcc-5
  Show dependency tree
Reported: 2015-08-01 16:14 UTC by Jory A. Pratt
Modified: 2015-09-17 15:13 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

inline patch (gnu-inline.diff,32.67 KB, patch)
2015-08-01 16:16 UTC, Jory A. Pratt
Details | Diff
Add a check against gcc-5 and C99 (fix_gcc_5_c99_inline.patch,1.06 KB, patch)
2015-09-10 10:53 UTC, Sven Eden
Details | Diff
dev-libs/ustr-1.0.4-r6.ebuild (ustr-1.0.4-r6.ebuild,1.30 KB, text/plain)
2015-09-10 10:54 UTC, Sven Eden

Note You need to log in before you can comment on or make changes to this bug.
Description Jory A. Pratt gentoo-dev 2015-08-01 16:14:53 UTC
Fails to inline using gcc-5.x

Reproducible: Always

Steps to Reproduce:
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':
Comment 1 Jory A. Pratt gentoo-dev 2015-08-01 16:16:12 UTC
Created attachment 408120 [details, diff]
inline patch
Comment 2 Sven Eden 2015-08-12 08:15:43 UTC
I'll look into it in the next few days.
Comment 3 Sven Eden 2015-09-10 10:51:19 UTC
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 (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.
Comment 4 Sven Eden 2015-09-10 10:53:10 UTC
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.
Comment 5 Sven Eden 2015-09-10 10:54:08 UTC
Created attachment 411490 [details]

Ebuild using the attached patch.
Comment 6 Ian Delaney (RETIRED) gentoo-dev 2015-09-13 04:39:50 UTC
This builds and installs.

commit 7dea6f8820f36bf389e6315044bea7507553bed0
Author: Ian Delaney <>
Date:   Sun Sep 13 11:14:45 2015 +0800

    dev-libs/ustr: revbump; patch and ebuild submitted in bug #556452
Comment 7 Sven Eden 2015-09-14 08:48:30 UTC
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.
Comment 8 Ian Delaney (RETIRED) gentoo-dev 2015-09-15 06:29:18 UTC
(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 <>
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.
Comment 9 Sven Eden 2015-09-16 07:57:58 UTC
(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.
Comment 10 Ian Delaney (RETIRED) gentoo-dev 2015-09-17 15:13:16 UTC
Not sure you can seek out and ask Arfrever but I suspect you might be missing FEATURES="multilib-strict in make.conf