Page MenuHomeFreeBSD

lang/gcc11: Install libgccjit.h and libgccjitg++.h in the intended path
ClosedPublic

Authored by salvadore on Nov 4 2022, 3:30 PM.
Tags
None
Referenced Files
Unknown Object (File)
Apr 3 2024, 12:25 PM
Unknown Object (File)
Apr 3 2024, 12:25 PM
Unknown Object (File)
Apr 3 2024, 12:25 PM
Unknown Object (File)
Apr 3 2024, 12:25 PM
Unknown Object (File)
Apr 3 2024, 12:12 PM
Unknown Object (File)
Mar 29 2024, 12:08 AM
Unknown Object (File)
Jan 2 2024, 6:33 PM
Unknown Object (File)
Jan 2 2024, 6:29 PM
Subscribers

Details

Summary

Fix bug introduced in commit c81d834b23446b10ac46c7f9378251baa11636b1
that installed libgccjit.h and libgccjitg++.h in

lib/gcc11/gcc/x86_64-portbld-freebsd13.1/include

instead of

/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.1/11.3.0/include

as it was intended.

PR: 257060
Reported by: yasu

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 48175
Build 45062: arc lint + arc unit

Event Timeline

This is how the patch was originally intended.

However, editors/emacs still fails to find libgccjit.h. Would it be possible to change the port so that it searches the header in /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd13.1/11.3.0/include ? Should I find a better directory where to put libgccjit.h?

If this takes too much time and build failure for emacs is a problem, feel free to revert c81d834b23446b10ac46c7f9378251baa11636b1 while we find the right solution.

The change here doesn't solve the problem with Emacs not finding the jit headers. After dc67e7d3009de2b78d96136c8ad09cf186e553df include/libgccjit.h and include/libgccjit++.h) are no longer installed.

I can get Emacs to successfully configure by adding this ugly line to the port Makefile.

CFLAGS+= -I${LOCALBASE}/lib/gcc11/gcc/x86_64-portbld-freebsd${OSREL}/11.3.0/include

Would it make more sense for GCC to modify the include path? Other ports are likely going to want these headers at some point.

Would it make more sense for GCC to modify the include path? Other ports are likely going to want these headers at some point.

Actually, at the moment GCC installs those headers in $(DESTDIR)$(includedir) and not where I have moved them, but this does not work either as it generates the conflict described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060 when a user attempts to install multiple versions of GCC. The location I tried was suggested in the upstream bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 that has not got any progress since 2022-01-20.

Are you aware of any location that would work both to avoid conflicts when installing multiple versions of GCC and to configure emacs properly?

I have reverted dc67e7d3009de2b78d96136c8ad09cf186e553df for now, so we can take our time with this without any issue for emacs.

Please see 9f0cd13014d0962aedfa016c86a5af07ca3ba814.

Recreate the patch after commit 9f0cd13014d0962aedfa016c86a5af07ca3ba814, which reverted dc67e7d3009de2b78d96136c8ad09cf186e553df.

I have built editors/emacs successfully with the patch in D37275.

I also confirmed combination with D37275 works fine on 13.1-RELEASE amd64.

This revision is now accepted and ready to land.Nov 5 2022, 9:56 AM