| Message ID | A0eOzVzqqzOM7JTk9Sak8YwMXwnh3tzC3lhGpAbnHcMdHPjKblcF3AA_28bvTWp1tZiRUI5eUHPY68mzGjQcPfjlzHpea18N5VQpoVzRSxQ=@protonmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [bug#40164] Fix for libgccjit | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
I forgot to say what it does - it adds «lib/gcc» to the CPATH so that we don't get errors like «ld: cannot find crtbeginS.o: No such file or directory».
it fixes LIBRARY_PATH, not CPATH
Hello Formbi,
> Empty Message
Could you explain what you are trying to fix with this patch?
Thanks,
Mathieu
Hello, Formbi <formbi@protonmail.com> skribis: > From 51511978f7e41392d9ed4d49f08c7ce154ff18d2 Mon Sep 17 00:00:00 2001 > From: Formbi <formbi@protonmail.com> > Date: Sat, 21 Mar 2020 14:10:01 +0100 > Subject: [PATCH] fix libgccjit > > --- > gnu/packages/gcc.scm | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm > index 08afd80358..2c9a8ba9df 100644 > --- a/gnu/packages/gcc.scm > +++ b/gnu/packages/gcc.scm > @@ -716,7 +716,17 @@ as the 'native-search-paths' field." > (for-each delete-file > (find-files (string-append (assoc-ref outputs "out") "/bin") > ".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)")) > - #t)))))))) > + #t)))))) > + (native-search-paths > + (list (search-path-specification > + (variable "C_INCLUDE_PATH") > + (files '("include"))) > + (search-path-specification > + (variable "CPLUS_INCLUDE_PATH") > + (files '("include"))) > + (search-path-specification > + (variable "LIBRARY_PATH") > + (files '("lib" "lib64" "lib/gcc"))))))) I think this has no effect because this ‘native-search-paths’ is already inherited from ‘gcc-9’, which ‘libgccjit’ inherits from. Can you confirm? Mathieu Othacehe <m.othacehe@gmail.com> skribis: > Could you explain what you are trying to fix with this patch? From a discussion on IRC, this has to do with the fact that libgccjit needs all these search paths defined at run time. Thanks, Ludo’.
> I think this has no effect because this ‘native-search-paths’ is already > inherited from ‘gcc-9’, which ‘libgccjit’ inherits from. Nope, it does have an effect. I added "lib/gcc" to the original paths (and that was the needed thing).
> I think this has no effect because this ‘native-search-paths’ is already > inherited from ‘gcc-9’, which ‘libgccjit’ inherits from. Nope, it does have an effect. I added "lib/gcc" to the original paths (and that was the needed thing). (sending again because I forgot about the debbugs e-mail)
Hi, (+Cc bug.) Formbi <formbi@protonmail.com> skribis: >> I think this has no effect because this ‘native-search-paths’ is already >> inherited from ‘gcc-9’, which ‘libgccjit’ inherits from. > > Nope, it does have an effect. I added "lib/gcc" to the original paths (and that was the needed thing). In that case, could you (1) arrange to write the search path in a way that reuses (package-native-search-paths gcc-9), and (2) add a comment explaining why “lib/gcc” is needed (it looks unusual)? Thanks in advance, Ludo’.
Hi, Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > (+Cc bug.) > > Formbi <formbi@protonmail.com> skribis: > >>> I think this has no effect because this ‘native-search-paths’ is already >>> inherited from ‘gcc-9’, which ‘libgccjit’ inherits from. >> >> Nope, it does have an effect. I added "lib/gcc" to the original paths (and that was the needed thing). > > In that case, could you (1) arrange to write the search path in a way > that reuses (package-native-search-paths gcc-9), and (2) add a comment > explaining why “lib/gcc” is needed (it looks unusual)? > > Thanks in advance, > Ludo’. Perhaps the original issue is the one reported/fix with a patch here [0] ? Formbi, could you share a simple reproducer so that we can test if the patches resolve it? It seems it'd be useful to upstream as well (to have a reproducer). Thanks! [0] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-03/msg01045.html
Hello again, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > Perhaps the original issue is the one reported/fix with a patch here [0] > ? Formbi, could you share a simple reproducer so that we can test if > the patches resolve it? It seems it'd be useful to upstream as well (to > have a reproducer). > > Thanks! > > [0] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-03/msg01045.html Another data point: this seems to be worked around in Nix using the fix proposed by Formbi: https://github.com/NixOS/nixpkgs/blob/8a815af4280f3e0d5ff740faa7d489e2b9e36829/pkgs/applications/editors/emacs/generic.nix#L87. Maxim
From 51511978f7e41392d9ed4d49f08c7ce154ff18d2 Mon Sep 17 00:00:00 2001 From: Formbi <formbi@protonmail.com> Date: Sat, 21 Mar 2020 14:10:01 +0100 Subject: [PATCH] fix libgccjit --- gnu/packages/gcc.scm | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm index 08afd80358..2c9a8ba9df 100644 --- a/gnu/packages/gcc.scm +++ b/gnu/packages/gcc.scm @@ -716,7 +716,17 @@ as the 'native-search-paths' field." (for-each delete-file (find-files (string-append (assoc-ref outputs "out") "/bin") ".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)")) - #t)))))))) + #t)))))) + (native-search-paths + (list (search-path-specification + (variable "C_INCLUDE_PATH") + (files '("include"))) + (search-path-specification + (variable "CPLUS_INCLUDE_PATH") + (files '("include"))) + (search-path-specification + (variable "LIBRARY_PATH") + (files '("lib" "lib64" "lib/gcc"))))))) (define-public gccgo-4.9 -- 2.25.0