Until now i haven't finde the Problem but your Patch is confusing because you check the same thing two time's if i see it correctly: Your check is: #if __GNUC__ >= 5 || GCC_VERSION >= 3004 With GCC_VERSION defined as: #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__) So you are checking if the major Version is greater than or equal GCC 5.x OR if the version is greater than or equal GCC 3.4 And i didn't see the sense in this expanded #if, or i overlook something. Greetings 2015-06-20 12:11 GMT+02:00 Giovanni Santini <giovannisantini93@yahoo.it>:

Hello everybody, I already wrote some days ago a message in this mailing list asking for help, but I noticed that email clients acted in weird ways (GMail on my Nexus and Thunderbird on my laptop acted in different ways for the same mail) so I'm writing you again.

I started to upload my packages to AUR4 and I tried to build them up in order to upload working packages... After GCC 5.X, I am not able to build anymore my package 'gcc44-multilib'. I had some problems in compiling (toplevel.c), that I fixed an hand-made patch, but then I have problems in linking (double defines for the function I fixed with my patch)...

If someone could give me an hand fixing the package out, it would be really great. AUR link: https://aur.archlinux.org/packages/gcc44-multilib/ AUR4 link: https://aur4.archlinux.org/packages/gcc44-multilib/ The edited PKGBUILD (including the new patch I made): https://dl.dropboxusercontent.com/u/4152736/gcc44-multilib_future.tar.gz The patch I wrote: https://dl.dropboxusercontent.com/u/4152736/gcc-fix_toplevel_defines.patch

If someone wants to help me, I can upload my source tarball (3rd link) to AUR4 so it can be fixed with Git.

Thank you for your attention.

-- Giovanni Santini My blog: http://giovannisantini.tk My code: https://github.com/ItachiSan

Am 20.06.2015 um 12:11 schrieb Giovanni Santini:

[...] I had some problems in compiling (toplevel.c), that I fixed an hand-made patch, but then I have problems in linking (double defines for the function I fixed with my patch)... [...]

tl;dr: Here[1] is a working patch. Reason it did not work before: GCC 5 is just strict and does not like multiple definitions of a function by default. There is a warning above the functions, it tells you the way the include/inline magic is done may be problematic. Reason it did not work after your patch: The way inline functions are treated changed with GCC5[2]. The two functions have been included and exported in all .c source files referencing the toplev.h header and therefore a name clash happened when linking them together. The solution: Define the functions statically. This way they still will be included in every .c file referencing the toplev.h header, but they will only be available from inside them, not exported. GCC will optimize them away anyways, if not used. After fiddling a bit with the source, I thought this problem should be known by the GCC devs (as they even made a comment about that broken magic) and therefore I looked a bit through the toplev.(c/h) from more recent versions. The code has since been refactored, but I found the relevant change in the gcc repository[3] (used github for better web view). The removed checks for the C*Z_HWI macros is because they will only be defined when using the faster inlined functions, but are useless in the fallback code. Hope this helps. best regards, carstene1ns [1]: https://paste.xinu.at/f32k/ [2]: https://gcc.gnu.org/gcc-5/porting_to.html ("Different semantics for inline functions") [3]: https://github.com/gcc-mirror/gcc/commit/4345dfaa7260253cb0d3b10b4b466f586e9...