Hi David,

> On 25 Jan 2024, at 10:16, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 

>> On 24 Jan 2024, at 18:31, David Malcolm <dmalcolm@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