bug#55657: libgccjit is unusable

[Liliana Marie Prikler]

Hi John,

Am Mittwoch, dem 03.08.2022 um 21:13 + schrieb John Kehayias:
> I didn't dive into the details and I'm not expert here, but it gave
> me the clues to work around it. Seems that where gccjit looks for
> things has some assumptions (bugs?) which we can fix at runtime with:
> 
> LIBRARY_PATH=$GUIX_ENVIRONMENT/lib/gcc/x86_64-unknown-linux-
> gnu/11.3.0:$LIBRARY_PATH ./gccjittest
> 
> The errors reported before were solved with this LIBRARY_PATH
> addition of the lib/gcc subdirectory. So, the test program runs in
> 
> guix shell gcc-toolchain@11 libgccjit@11 --pure
> 
> where I compiled to gccjittest following the tutorial directions (no
> change to LIBRARY_PATH).
while this does help insofar as I now know which snippet I forgot to
copy, I do still think that this leaves us with two unreasonable
options if we want to use emacs to compile other packages:

1. Propagate gcc-toolchain from emacs.
2. Patch LIBRARY_PATH not just before configuration, but also via a
wrapper.

At the very least I don't see how Emacs would be able to compile other
packages to native code without either of the above.

WDYT?

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

Found out some useful info and a work around for the original reported issue of 
the simple "hello world" of gccjit not working.


--- Original Message ---
On Tuesday, June 28th, 2022 at 1:16 AM, John Kehayias wrote:

> Hi,
>
> --- Original Message ---
> On Tuesday, June 28th, 2022 at 12:17 AM, Liliana Marie Prikler wrote:
>
> > Keyword here is "has worked for emacs". I've tried porting the logic
> > from flatwhatson's channel over, but regardless of what I do, it
> > already fails in the configure step of Emacs (in a manner that's
> > reproducible outside as well). Thus, I think this is a bug in
> > libgccjit (or perhaps our packaging of it) that simply happened to be
> > ignored during development of Emacs 28, but no longer in the release.
>
>
> Sorry, I should be extra clear that I mean has in the past and continues to 
> work for Emacs. I've been using emacs-pgtk-native-comp through the 
> flatwhatson channel from well before v28 was released. Currently I'm using 
> emacs-pgtk-native-comp-28.1.50-223.3ddccb5. Everything has built, installed, 
> and run fine for as long as I have been using it. Just in case that was in 
> question, and as a point of reference.
>
> Anyway, I'll try to reproduce when I can (tomorrow likely) what you reported 
> in the first message using this setup, if that is of use.
>

I was able to reproduce the original error, though I used the libgccjit package 
from the flatwhatson channel, at v11.3.0 (along with GCC at that version). For 
good measure, I also used the tutorial at that version, just in case 
https://gcc.gnu.org/onlinedocs/gcc-11.3.0/jit/intro/tutorial01.html  I chose 
this version since that is what emacs-native-comp from that channel is built 
with.

Searching for these error messages of missing libraries/files, I found

https://ref.strikr.io/jit/internals/index.html#environment-variables

and a bug report at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808

I didn't dive into the details and I'm not expert here, but it gave me the 
clues to work around it. Seems that where gccjit looks for things has some 
assumptions (bugs?) which we can fix at runtime with:

LIBRARY_PATH=$GUIX_ENVIRONMENT/lib/gcc/x86_64-unknown-linux-gnu/11.3.0:$LIBRARY_PATH
 ./gccjittest

The errors reported before were solved with this LIBRARY_PATH addition of the 
lib/gcc subdirectory. So, the test program runs in

guix shell gcc-toolchain@11 libgccjit@11 --pure

where I compiled to gccjittest following the tutorial directions (no change to 
LIBRARY_PATH).

So, looking at the emacs-native-comp definition in flatwhatson, we can see that 
a phase is used to set LIBRARY_PATH before configure just as I did here: 
https://github.com/flatwhatson/guix-channel/blob/master/flat/packages/emacs.scm#L65

Hope this is helpful and unblocks libgccjit and emacs-native-comp for Guix!

John

bug#56956: rust-pico-sys bundles PicoHTTPParser.

[Maxime Devos]

X-Debbugs-CC: Efraim Flashner 

(^ original package author+committer)

rust-pico-sys was added in commit
.

This package bundles PicoHTTPParser.

Fortunately, it is only used by a single dependency: rust-httparser, and 
only for benchmarks (which probably aren't compiled anyway), so simply 
removing the package definition and removing it from rust-httparser' 
#:dev-dependencies should be sufficient.  This appears to work in 
antioxidant.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#54691: fortune-mod propagates various non-nice things

[Liliana Marie Prikler]

Hi Ludo,

Am Mittwoch, dem 03.08.2022 um 15:43 +0200 schrieb Ludovic Courtès:
> [...]
> > -(define-public fortune-mod
> 
> (Perhaps also make “fortune-mod” a deprecated name for
> “fortune-jkirchartz”.)
I'm getting mixed messages here.  On the one hand, Maxime suggests not
propagating daikichi from fortune-jkirchartz (which makes it a plain
data package lacking a `fortune' command), on the other we want to mark
fortune-mod as deprecated.  These are mutually exclusive options.

> FWIW I’m fine with this change.  Note that there’s also another patch
> that removes the ‘off’ database of ‘fortune-mod’¹, though I don’t
> know whether that would fully address the issues raised in this
> thread.  It will have to closed if/once this series is applied.
IIRC, I responded to such a patch already, though perhaps not that
thread in particular.  To summarize, fortune-mod also propagates non-
nice things outside of ‘off’, so removing it is not enough.


Cheers

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> I'll be the road for a while, unable to work on this patch, so if anyone
> wants to work on it and merge, please go ahead :)
>
> Left to do:
>
> - Suggestion: add a keyword to choose between asdf:compile-system and
>   asdf:load-system (default should be asdf:load-system).
> - Make sure sbcl-stumpwm-kbd-layouts usees asdf:compile-system.
> - Rebuild the Lisp world to test.

I added a 'asd-operation' keyword parameter with a default value of
"load-system", and I used it in the package definition of
sbcl-stumpwm-kbd-layouts to use "compile-system" instead.

Patches pushed as 6b5ef03a2582ab23228478018fd356e17db1daea and
following.


signature.asc
Description: PGP signature

bug#54691: fortune-mod propagates various non-nice things

[Ludovic Courtès]

Hi,

Liliana Marie Prikler  skribis:

> Since the addition of fortune-jkirchartz, it is no longer necessary to
> keep around a package that propagates various non-nice things.
> For a complete list, see .
>
> * gnu/packages/games.scm (fortune-mod): Delete variable.

[...]

> -(define-public fortune-mod

(Perhaps also make “fortune-mod” a deprecated name for
“fortune-jkirchartz”.)

FWIW I’m fine with this change.  Note that there’s also another patch
that removes the ‘off’ database of ‘fortune-mod’¹, though I don’t know
whether that would fully address the issues raised in this thread.  It
will have to closed if/once this series is applied.

Thanks,
Ludo’.

¹ https://issues.guix.gnu.org/56599

bug#56893: [Pkg-rust-maintainers] Bug#1016546: rust-vergen inserts build timestamps

[Fabian Grünbichler]

On August 2, 2022 10:16 pm, Maxime Devos wrote:
> On 02-08-2022 20:41, Geert Stappers wrote:
> 
>> Date: Tue, 2 Aug 2022 19:18:46 +0200, From: Maxime Devos
>>> In Guix, I've noticed that rust-vergen embeds build timestamps. There is 
>>> also
>>> a work-around available: .
>>   
>>
>> Thanks for reporting the FTBR.
>>
>> Please update the workaround, so it looks more
>> like https://en.wikipedia.org/wiki/Diff#Unified_format
>> and can be absured by https://en.wikipedia.org/wiki/Patch_(Unix)
>>
>>
>> Just telling the filename that needs modification would be a great help.
> 
> Oops, I did not send the full work-around, here it is:
> 
>>      (substitute* (find-files "." "\\.rs$")
>>        (("^extern crate chrono;") "extern crate chrono; use 
>> chrono::Utc; use chrono::TimeZone;")
>>        (("^use chrono::Utc;") "use chrono::Utc; use 
>> chrono::TimeZone;")
>>        (("\\bUtc::now\\(\\)") "Utc.timestamp(0, 0)"))
> (Should hopefully be clearer now!)
> 
> The important thing here is replacing all instances of Utc::now() 
> (across all Rust source files of rust-vergen) by Utc.timestamp(0, 0), 
> the rest is just adding the required imports -- I have not made a list 
> of all file names.  If you want a list, try "grep -rF Utc::now" or such.
> 
> I do not intend to update the workaround, it works fine in Guix and 
> frankly porting it to whatever format Debian likes is Debian's concern, 
> not Guix', I'm just sharing our workaround as a courtesy to another distro.

also note that for debian purposes, we likely want to honor 
SOURCE_DATE_EPOCH instead of setting it to epoch zero.