Mailing List Archive

Packaging Trinity--looking for help
The short version: we're looking for someone with knowledge of
autotools, ebuilds, and, ideally, the eclasses from kde-sunset
(which is why I'm posting this here) who's willing to contribute a
bit of time to help us unravel a mysterious build failure.

The long version: Trinity, the fork of KDE3, is currently in the
middle of converting from the old autotools-based KDE build system
to a more maintainable setup based on cmake.

I'm part of a small group of people (currently two-and-a-fraction)
trying to package Trinity for Gentoo and related distros (for a little
info on where we're at, see
http://wiki.hasnoname.de/tde:trinity-overlay_on_funtoo_gentoo ).
What we've found is that the packages that have already been
converted to cmake can easily be wrapped with ebuilds, but some
of the autotools-based packages break.

Upstream is not doing anything but the most vital fixes to the
autotools system—they're really short on manpower. That means
creating a patch to handle the problem until the cmake conversion
is complete, which is likely to be at least a year in the future . . . and
this is where our group is running into problems, because we don't
have anyone who understands Makefile syntax at the level needed
to grasp everything going on in the old build system.

The best we've managed to be able to do is get the builds to reach
the linker stage, where they break due to missing libraries which we
seem to be unable to reinject—append-libs and various methods of
manipulating LDFLAGS within the ebuilds seem to do nothing. Our
attempts to work on the build system itself have so far only resulted
in it failing earlier.

<small_voice>Help?</small_voice>
Re: Packaging Trinity--looking for help [ In reply to ]
E. Liddell posted on Mon, 19 Mar 2012 12:26:52 -0400 as excerpted:

> The long version: Trinity, the fork of KDE3, is currently in the middle
> of converting from the old autotools-based KDE build system to a more
> maintainable setup based on cmake.

> The best we've managed to be able to do is get the builds to reach the
> linker stage, where they break due to missing libraries which we seem to
> be unable to reinject—append-libs and various methods of manipulating
> LDFLAGS within the ebuilds seem to do nothing.

I've no idea if this will help or not, or whether you've tried it or not,
but...

It occurs to me that kde3 was probably "sunsetted" before gentoo's switch
to --as-needed linker flags by default. Now I switched to --as-needed
here, long before gentoo switched its default, and /think/ I was running
that here for some time before I upgraded to kde4. If I'm correct, then
kde3 as it was back then, at least, could run with --as-needed, but I'm
not sure if it stayed that way or what patches gentoo might have already
been using at the time in ordered to make it work, that might well need
updating to /keep/ it working.

So, umm... yeah, try disabling the --as-needed linking, thus triggering
overlinking in many cases, but possibly helping here, and see if it helps.

But I'm not the autotools guru you're looking for. Sorry. This kinda
sorta sounds like it might help, but maybe not, too. Maybe it's a
combination of this so it doesn't ignore your appended libs, tho, and
actually appending the libs? That's what I thought of first when reading
your description, but I'd guess you've already tried it, too. Still,
it's worth the suggestion, just in case...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: Packaging Trinity--looking for help [ In reply to ]
On Tue, 20 Mar 2012 04:43:53 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> E. Liddell posted on Mon, 19 Mar 2012 12:26:52 -0400 as excerpted:
>
> > The long version: Trinity, the fork of KDE3, is currently in the middle
> > of converting from the old autotools-based KDE build system to a more
> > maintainable setup based on cmake.
>
> > The best we've managed to be able to do is get the builds to reach the
> > linker stage, where they break due to missing libraries which we seem to
> > be unable to reinject—append-libs and various methods of manipulating
> > LDFLAGS within the ebuilds seem to do nothing.
>
> I've no idea if this will help or not, or whether you've tried it or not,
> but...
>
> It occurs to me that kde3 was probably "sunsetted" before gentoo's switch
> to --as-needed linker flags by default. Now I switched to --as-needed
> here, long before gentoo switched its default, and /think/ I was running
> that here for some time before I upgraded to kde4. If I'm correct, then
> kde3 as it was back then, at least, could run with --as-needed, but I'm
> not sure if it stayed that way or what patches gentoo might have already
> been using at the time in ordered to make it work, that might well need
> updating to /keep/ it working.
>
> So, umm... yeah, try disabling the --as-needed linking, thus triggering
> overlinking in many cases, but possibly helping here, and see if it helps.
>
> But I'm not the autotools guru you're looking for. Sorry. This kinda
> sorta sounds like it might help, but maybe not, too. Maybe it's a
> combination of this so it doesn't ignore your appended libs, tho, and
> actually appending the libs? That's what I thought of first when reading
> your description, but I'd guess you've already tried it, too. Still,
> it's worth the suggestion, just in case...

I suspected the --as-needed flag of being the culprit at first myself,
but it turned out not to be that simple—the switches that would add
the libs just refuse to appear in the ld command, even if --no-as-needed
is passed. Adding the libs manually to the end of the line makes the
command go through, but that doesn't help with the ebuild.

Thanks for trying, though.

E. Liddell