Public SourceMage Discussion List

[Javier Vasquez <j.e.vasquez.v AT gmail.com>]

On Tue, Dec 3, 2013 at 8:36 AM, Sukneet Basuta <sukneet AT gmail.com> wrote:
> On 02/12/13 01:57 AM, Javier Vasquez wrote:
>> On Sat, Nov 9, 2013 at 11:41 AM, Remko van der Vossen <wich AT yuugen.jp> 
>> wrote:
>>> On 2013/11/09, at 5:29, Sukneet Basuta <sukneet AT gmail.com> wrote:
>>>> I haven't had the the time to work on this in over 2 months, so I'm 
>>>> giving up on it. I've attached a git patch that adds a bunch of spells 
>>>> to libpthread-stubs' UP_TRIGGERS that should get a working system at 
>>>> least. However, the problem is that I can't get the spells to cast in 
>>>> the correct order (adding dependencies ends up with cyclical 
>>>> dependencies). So you have to keep recasting libpthread-stubs until 
>>>> everything compiles okay. This is not a proper upgrade path imo, but I 
>>>> couldn't think of anything better given the current limitations of 
>>>> Sorcery.
>>>>
>>>> This isn't a complete list either since I gave up adding spells to it 
>>>> after a bit and instead focused on trying to get spells to cast in the 
>>>> correct order. If the leads decide to merge this, I'll try to eventually 
>>>> compile a complete list of spells that need recasting.
>>>
>>> Yes, I think this is the biggest problem we have in Source Mage. libpng 
>>> suffers from exactly the same problem, as did the libxcb upgrade we 
>>> suffered through some years back. The unnecessary deep linking that is 
>>> done by libtool only exacerbates the problem, hence my suggestion to move 
>>> forward on --as-needed a while back. But that will only improve matters, 
>>> it will not completely solve them.
>>>
>>> I think the only proper way to solve this is to have sorcery collect the 
>>> link dependencies from the installed spells, in the case of ELF dynamic 
>>> objects, the spells that provide each of the listed DT_NEEDED entries in 
>>> the dynamic objects, even if the listed entry is not directly used, as 
>>> building anything that links to that object will fail if the dynamic 
>>> object in the entry does not exist anymore. Then, when casting anything, 
>>> sorcery needs to know about incompatible upgrades, build a tree of link 
>>> dependent spells ignoring dependencies in DEPENDS for this tree, and 
>>> immediately cast those spells in the correct order. We still have to see 
>>> about resolving any cyclic dependencies if there are any, and it should 
>>> be seen whether these spells should be cast from the grimoire or from 
>>> tablet. Then and only then should sorcery continue casting its normal 
>>> queue, meaning that the link dependency triggered queue should be 
>>> separate from the normal cast/install queue.
>>>
>>> This would of course mean a big change in sorcery though and given the 
>>> lack of time and motivation for any big sorcery work, I don't think this 
>>> is going to happen anytime soon.
>>>
>>> Regards, Remko
>>
>>
>> Can a planar list of casts (no matter if some get repeated) be created
>> so that at the end all dependencies issues get solved by casting spell
>> by spell, one at a time?  If so, perhaps documenting such list of
>> steps might be a work around...
>>
>>
>
> Hmm, thinking about it, this may be a viable option by chaining
> commands. I don't have the time to work on this currently though. If
> someone else wants to step in (I already made a pretty good list of
> spells above), please do. :)

I'm not using devel-xorg-modular, I'm using test, with several spells
from devel-xorg-modular and some other spells missing from
devel-xorg-modular.

I went through the exercise to cast libpthread-stubs 0.3, gotten from
devel-xorg-modular.

The process was actually quiet smooth compared to the libpng one.  The
only fix required from my part was libxft.  Both the test versions and
the devel-xorg-modular depend on freetype2, but 2 headers needed by
libxft are used from /usr/include/freetype, which is wrong bacause the
freetype2 headers are found on /usr/include/freetype2.  See:

http://www.sourcemage.org/issues/627

After fixing that, I found no problems, other than the need for a 2nd
pass of the spells dependent upon libpthread-stubs, given the fonts
not looking good on gtk+*.

I mixed the casting of dynamically linking dependencies the spell on
devel-xorg-modular had, with casting the spells directly dependent on
libpthread-stubs, with the spells provided by Sukneet, and that worked
out well (2 triggers required).  See attachment.

The spells I already had casted, given I moved to gcc 4.7.6 at some
point, and now I'm with gcc 4.8.2 are the ones I mentioned in my last
comment on an old closed bug, but perhaps some additional ones:

http://www.sourcemage.org/issues/530

In essence the libpthreads-stubs looks a cleaner update than the
libpng one, but perhaps it has to do with casting all those spells
1st, :-)

What I'll need to do next will be to set "as-needed" as my LDFLAGS,
and at some point performs "cast -r", but that takes time...

Also I'll need to see what spell to bring from devel-xorg-modular on
top of test.  If someone has a list, that'd be great.  If not, then
I'll have to script a little bit to at least find out which spells are
newer on devel...

Thanks,

-- 
Javier.

Attachment: libpthread-stubs.tar.xz
Description: Binary data