Aside from these libtool files we can now say, that this ddc project
succeeded.
I've contacted the libtool developers if we can extend the wrapper approach
to the .la files.
It seems, that in some older version of libtool those were just sourced as
shell script, but
I don't know if now they do something more fancy with it or not...
Anyways, if it's just shell script, then the environment variable approach
can also work out there.
The only problem seems, that I should do the substitution before
checksumming the compiler.
I think I can inject something into the makefile, or use a patched vesion
of libtool.

A patched libtool could be a better option, so other ddc projects can use
it.
I guess I can do something like add an environment variable
GUIX_INSTALL_DIRECTORY, or something like that...
Any maybe name this version libtool-for-ddc.
It should be noted in the package documentation, that this package is not
recommended for general use.

WDYT?


2017-11-30 15:32 GMT+01:00 Gábor Boskovits <boskov...@gmail.com>:

> It seems, that the libtool file differences leak into the checksum.
> I will try to contact developers on how to bypass that issue.
>
>
> 2017-11-29 16:57 GMT+01:00 Jan Nieuwenhuizen <jann...@gnu.org>:
>
>> Gábor Boskovits writes:
>>
>> > It seems, that I can make really good progress here.
>> > Now the only things that remain:
>>
>> Great!
>>
>> > The libtool .la files record the installation directory, these are
>> textfile wrappers anyways, so I don't know if
>> > we should care about this.
>>
>> How about asking the libtool developers?
>>
>> > The mkheaders shell srcipt in install-tools record the installation
>> directory, this is in source form by the
>> > way, so I don't know if we should care about this.
>>
>> In a way similar to the libtool wrappers: the build is still
>> reproducible in a way; just harder to check with Guix.  Having
>> everything below /gnu/store/deadbeef-gcc-4.7.4 identical could be a
>> feature, but possibly something left for later.
>>
>> > The only remainig problem is that the symbol executable_checksum in cc1
>> and cc1plus still differ. No other
>> > differences remained.
>>
>> OK!
>>
>> > I'm now investigating the checksum issue.
>>
>> Great to hear your progress
>> janneke
>> --
>> Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org
>> Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
>>
>
>

Reply via email to