On 16 March 2017 at 22:24, Kevin Kofler <kevin.kof...@chello.at> wrote:
> The thing is, proprietary applications statically linking to glibc are > highly likely to be in violation of the LGPL. Or how many proprietary > applications do you know that distribute their object files (and/or their > source code) to allow relinking against a modified glibc? > [mode=kidding] So stop provide glibc-static and redirect those guys to /dev/tree in uClibc garden may be kind of "solution" how to block (easy way) violating LGPL .. [/mode] I have no even murky idea how many proprietary applications may be on such list. TBH all proprietary applications binaries which I know are definitely at least dynamically linked with glibc. Really some people are .. "curving" such "sculptures" ? =8-o ucLibc has the same issue, by the way. musl (https://www.musl-libc.org/) is > a more reasonable choice for people who want to ship a statically-linked > proprietary blob. And, unlike glibc, musl is also designed for static > linking. > Hmm .. so probably this behavior was introduced in last few years. I'm 100% sure that decade ago was possible to produce uClibc based static binaries not affected by NSS ABI issue. Maybe it is some uClibc build option allowing disable NSS support (?) (I really like coding style of uClibc which been telling me that those guys grinding this code are really caring about every small detail) Good to know that it is still some alternative which could be considered as glibc-static replacement. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
