[systemd-devel] build failures in latest master from d848b9cbfa0ba72381363accce481600169df2eb

[Kay Sievers]

On Thu, Feb 7, 2013 at 10:28 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Thu, Feb 07, 2013 at 02:38:26PM +0100, Kay Sievers wrote:
>> On Thu, Feb 7, 2013 at 7:32 AM, Zbigniew Jędrzejewski-Szmek
>> <zbyszek at in.waw.pl> wrote:
>> > On Tue, Feb 05, 2013 at 02:43:32PM +0100, Michael Biebl wrote:
>> >> 2013/2/5 Colin Walters <walters at verbum.org>:
>> >> > On Tue, 2013-02-05 at 13:10 +0100, Kay Sievers wrote:
>> >> >
>> >> >> We do not want to place shared libraries with private APIs in the
>> >> >> system. Other people might rely on stuff which we can never track.
>> >> >
>> >> > Note that it installs into a private subdirectory, so people writing
>> >> > apps can't just use -lsystemd-shared in their linker lines in their
>> >> > build systems, and unless they also go to the effort of adding an rpath
>> >> > or LD_LIBRARY_PATH for /usr/lib/systemd/private to their executables,
>> >> > dynamic linking will also fail.
>> >>
>> >> Please don't add such a private shared library. Aside from being ugly
>> >> and having systemd and it's tools have to use an RPATH, it makes (as
>> >> already mentioned) packaging udev separately harder. I think a few KB
>> >> of disk space do not warrant that change.
>> > OK, I guess that this is not an option.
>> >
>> > I now pushed a simple patch from David Strauss which adds an additional
>> > dependency and fixes the build.
>>
>> We cannot do that. Libudev should not link the dynamic libs from systemd.
>>
>> I changed it now and people with the non-working --as-needed need to
>> check if that works for them ...
> Thanks, your approach is much better. Is is actually necesary
> to apply the same fix to libsystemd-journal. I'm pushing a fix.

Ah. nice, that it seems to works. Thanks a lot for taking care of the rest.

Kay