Hi David, > On 25 Jan 2024, at 10:16, Iain Sandoe <i...@sandoe.co.uk> wrote: >
>> On 24 Jan 2024, at 18:31, David Malcolm <dmalc...@redhat.com> wrote: >> >> On Tue, 2024-01-16 at 11:10 +0000, Iain Sandoe wrote: >>> Tested on x86_64, i686 Darwin and x86_64 Linux, >>> OK for trunk? when ? >>> thanks, >>> Iain >> >> Hi Iain, thanks for the patch. >> >> I'll have to defer to your Darwin expertise here; given that you've >> tested it on the above configurations I'll assume it's correct, but... >> >>> >>> --- 8< --- >>> >>> Currently, we have no exports list for libgccjit, which means that >>> all symbols are exported, including those from libstdc++ which is >>> linked statically into the lib. This causes failures when the >>> shared libstdc++ is used but some c++ symbols are satisfied from >>> libgccjit. >>> >>> This implements an export file for Darwin (which is currently >>> manually created by cross-checking libgccjit.map). >> >> ...I'm a little nervous about this; Antoyo has a number of out-of-tree >> patches we're working towards merging, and almost all of these touch >> libgccjit.map. >> >> >>> Ideally we'd >>> script this, at some point. >> >> Yes. How about a Python 3 script (inside "contrib", or in "gcc/jit") >> that would do that. > > I’m not sure we want to make a build dependency on Python 3.. > the reason I say ‘build’ is ... > >> Then whenever a patch touches libgccjit.map we'd >> run that script to regenerate libgccjit.exp in the source tree. I can >> have a go at writing it, if you think that's the best way to go. > > … there are two other places in the current sources where ld map files > are converted to Darwin (and Solaris) symbol export files [libgcc, libstdc++]. > > In these cases, the export file is created on-the-fly at build time by scripts > (IIRC a mixture of awk, sh, perl). > > This requires more surgery to the Make stuff and that we have a suitable > script - but it does mean that we do not need to commit the Darwin (and > potentially Solaris) versions to the source tree. > > I’m actually happy with either solution - since we do not expect this to > be a daily occurance, we could have a maintainter’s python3 script to > update a committed export file or we could try the mechanism used in > the other two places (but then the script would need to use awk/sh/perl > to avoid new build deps). > >> I take it .exp is the standard extension for these exports file in the >> Darwin world. If so, it's a shame (but unavoidable) that it clashes >> with the existing uses of .exp in our source tree for our >> expect/Tcl/DejaGnu sources. > > I suspect the linker will accept other extensions, although ‘exp’ is a > convention used elsewhere, it is unfortunate that it clashes indeed. > - let me try an alternate (e.g. .export) and report back. > >> I think the patch as-is is OK for trunk now, assuming that you've >> tested it as above. > > I’m going to hold off on this for now (but do want some solution before > 14 branches, because there are quite a few new fails from it). It seems that we are not going to get time to implement something better for GCC-14; this is what I applied (I renamed the extension to .exports which the linker is fine with) so that it is not confused with .exp files. I guess I’ll need to do a final pass of checking I’ve copied all the syms before 14 branches. thanks Iain
0001-jit-Darwin-Implement-library-exports-list.patch
Description: Binary data
