Bastien Nocera wrote:
> That's a problem for OUR users because when they use Fedora, they want to
> be able to make a tarball of their software for their friend on Ubuntu to
> test. Here, you're making Fedora a bad choice for developers that want to
> target more than just Fedora.
This already does not work even now, due to glibc. See my reply to drago01.
(You need to compile in something like a CentOS chroot if you want binaries
that have any chance of working cross-distro.)
>> GCC supports __attribute__((deprecated("message"))) these days. So we can
>> tag the added functions with something like:
>> __attribute__((deprecated("nonstandard function added by a non-upstream
>> patch to make FooApp work, use in other applications strongly
>> discouraged")))
>>
>> If the developers opt to use those functions anyway, then that's not our
>> problem.
>
> This isn't made to tag symbols that aren't upstream, and the end-user
> application will just barf out with unresolved symbols when you try to run
> it, which is far from useful.
That's the developer's fault for ignoring the warning then. There are
already plenty of other ways to make your code intentionally non-portable
(e.g., reading the OS version from /etc/fedora-release). What the attribute
does is ensuring it won't happen by accident.
> I'll ask something, in earnest: have you ever written and shipped
> non-trivial software on Linux?
Yes. Which is why I know that attempting to compile cross-distro binaries on
Fedora is a lost cause anyway.
And frankly, it really surprises me that people think that shipping a system
library with some functions patched in is somehow worse than shipping BOTH
an unmodified system library AND a patched library (or more) bundled with
some application(s). Sharing code should be the prime goal, and added
functions do not hurt anybody.
Kevin Kofler
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
