bug#45934: native-comp - Dylib ID of ELN files not optimal

bug#45934: native-comp - Dylib ID of ELN files not optimal

[davide.restivo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi, 

I'm currently maintaining an Homebrew formula [1] for GNU/Emacs on macOS
and I have recently added to it support for the native-comp feature.
While doing this I have realised that current dylib IDs of the ELN files
might be improved to avoid an issue I have encountered.

Currently whenever and ELN file is generated, the dylib ID has the
following structure: /private/tmp/libgccjit-xxxxxx/fake.so. See below
examples:

Example_1:
Filename:  
   /usr/local/Cellar/emacs-head@28/28.0.50_1/Emacs.app/Contents/native-lisp/28.0.50-x86_64-apple-darwin19.6.0-280c4c724fff373c5b7192112ad4147c/4Corner-80465fd1980e15f97a4c37918242ae86-c113fb0ce90e32f79bf944d3da555eea.eln
dylib ID: 
  /private/tmp/libgccjit-3AyZly/fake.so

Example_2:
Filename:  
   /usr/local/Cellar/emacs-head@28/28.0.50_1/Emacs.app/Contents/native-lisp/28.0.50-x86_64-apple-darwin19.6.0-280c4c724fff373c5b7192112ad4147c/5x5-a61d71cfcb41ac534af48635fb74337a-d665a8dec895c4d242614826b692b6ba.eln
dylib ID: 
  /private/tmp/libgccjit-aVl48M/fake.so

The dylib IDs of two different ELN are unique (this is required by
macOS).

Homebrew compiles GNU/Emacs in a 'sandbox' directory and then it moves
 the artifacts to the final directory location (i.e.
 /usr/local/Cellar/emacs-head@28/28.0.50_1). While doing that it changes
 the dylib ID of the ELN files. For example:

==> Changing dylib ID of /usr/local/Cellar/emacs-head@28/28.0.50_1/Emacs.app/Contents/native-lisp/28.0.50-x86_64-apple-darwin19.6.0-280c4c724fff373c5b7192112ad4147c/4Corner-80465fd1980e15f97a4c37918242ae86-c113fb0ce90e32f79bf944d3da555eea.eln
  from /private/tmp/libgccjit-3AyZly/fake.so
    to /usr/local/opt/emacs-head@28/Emacs.app/Contents/native-lisp/28.0.50-x86_64-apple-darwin19.6.0-280c4c724fff373c5b7192112ad4147c/fake.so

==> Changing dylib ID of /usr/local/Cellar/emacs-head@28/28.0.50_1/Emacs.app/Contents/native-lisp/28.0.50-x86_64-apple-darwin19.6.0-280c4c724fff373c5b7192112ad4147c/5x5-a61d71cfcb41ac534af48635fb74337a-d665a8dec895c4d242614826b692b6ba.eln
  from /private/tmp/libgccjit-aVl48M/fake.so
    to /usr/local/opt/emacs-head@28/Emacs.app/Contents/native-lisp/28.0.50-x86_64-apple-darwin19.6.0-280c4c724fff373c5b7192112ad4147c/fake.so

Since the tmp directory is stripped out and replaced with the
destination directory, as you can see, all of the ELN files ends up with
the same dylib ID, and this is not allowed on macOS. My suggestion here
would be to add the 'install_name' [2] flag to gcc during the ELN files
compilation replacing the 'fake.so' with the original .eln filename.

Thanks and regards,
Davide


[1] https://github.com/daviderestivo/homebrew-emacs-head
[2] gcc -o libdummy.dylib -install_name ${PREFIX}/lib/libdummy.dylib 

bug#45934: native-comp - Dylib ID of ELN files not optimal

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"davide.restivo--- via \"Bug reports for GNU Emacs, the Swiss army knife
of text editors\"" <bug-gnu-emacs@gnu.org> writes:

[...]

> Since the tmp directory is stripped out and replaced with the
> destination directory, as you can see, all of the ELN files ends up with
> the same dylib ID, and this is not allowed on macOS. My suggestion here
> would be to add the 'install_name' [2] flag to gcc during the ELN files
> compilation replacing the 'fake.so' with the original .eln filename.
>
> Thanks and regards,
> Davide
>
>
> [1] https://github.com/daviderestivo/homebrew-emacs-head
> [2] gcc -o libdummy.dylib -install_name ${PREFIX}/lib/libdummy.dylib 

Hi Davide,

I'm really ignorant on MacOS so I'll comment for what I can.  I had a
look to the GCC doc [1] but I could not figure out if '-install_name' is
an option that goes to the compiler or the linker (nor I know what this
dylib ID exactly is).  If the flag is routed to the linker we should be
able to add it but only when libgccjit >= 9 is used.

Could you run a random compilation of something using '-install_name'
but adding also '-v' and report the console output so we can see where
the driver is routing the flag?

Thanks

  Andrea

[1] https://gcc.gnu.org/onlinedocs/gcc/Darwin-Options.html

bug#45934: native-comp - Dylib ID of ELN files not optimal

[davide.restivo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Andrea,

A dylib (extension .dylib) is the same as a GNU/Linux shared object (extension .so). Please find below the requested output:

```
$ /usr/local/bin/gcc-10 --version
gcc-10 (Homebrew GCC 10.2.0_2) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /usr/local/bin/gcc-10 -v -dynamiclib Ratings.c -install_name /usr/lib/ratings.dylib -o ratings.dylib
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin19/10.2.0/lto-wrapper
Target: x86_64-apple-darwin19
Configured with: ../configure --build=x86_64-apple-darwin19 --prefix=/usr/local/Cellar/gcc/10.2.0_2 --libdir=/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_2' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Homebrew GCC 10.2.0_2)
COLLECT_GCC_OPTIONS='-v' '-Zdynamiclib' '-Zinstall_name' '/usr/lib/ratings.dylib' '-o' 'ratings.dylib' '-mmacosx-version-min=10.15.0' '-asm_macosx_version_min=10.15' '-mtune=core2'
 /usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin19/10.2.0/cc1 -quiet -v -D__DYNAMIC__ Ratings.c -fPIC -quiet -dumpbase Ratings.c -mmacosx-version-min=10.15.0 -mtune=core2 -auxbase Ratings -version -o /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//ccN17V5Q.s
GNU C17 (Homebrew GCC 10.2.0_2) version 10.2.0 (x86_64-apple-darwin19)
	compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../../../../../x86_64-apple-darwin19/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/include
 /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks
End of search list.
GNU C17 (Homebrew GCC 10.2.0_2) version 10.2.0 (x86_64-apple-darwin19)
	compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 966ca361396c29aa9c1bedc558ef6a08
COLLECT_GCC_OPTIONS='-v' '-Zdynamiclib' '-Zinstall_name' '/usr/lib/ratings.dylib' '-o' 'ratings.dylib' '-mmacosx-version-min=10.15.0'  '-mtune=core2'
 as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.15 -o /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//cccaMqmZ.o /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//ccN17V5Q.s
Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx10.15.0 -filetype obj -main-file-name ccN17V5Q.s -target-cpu penryn -fdebug-compilation-dir /Users/gutter/Downloads -dwarf-debug-producer "Apple clang version 12.0.0 (clang-1200.0.32.28)" -dwarf-version=4 -mrelocation-model pic -o /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//cccaMqmZ.o /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//ccN17V5Q.s
COMPILER_PATH=/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin19/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin19/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin19/:/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/
LIBRARY_PATH=/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/:/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-Zdynamiclib' '-Zinstall_name' '/usr/lib/ratings.dylib' '-o' 'ratings.dylib' '-mmacosx-version-min=10.15.0'  '-mtune=core2'
 /usr/local/Cellar/gcc/10.2.0_2/libexec/gcc/x86_64-apple-darwin19/10.2.0/collect2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/ -dynamic -dylib -arch x86_64 -dylib_install_name /usr/lib/ratings.dylib -macosx_version_min 10.15.0 -weak_reference_mismatches non-weak -o ratings.dylib -L/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../.. /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//cccaMqmZ.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
collect2 version 10.2.0
/usr/bin/ld -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/ -dynamic -dylib -arch x86_64 -dylib_install_name /usr/lib/ratings.dylib -macosx_version_min 10.15.0 -weak_reference_mismatches non-weak -o ratings.dylib -L/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../.. /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//cccaMqmZ.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
@(#)PROGRAM:ld  PROJECT:ld64-609.8
BUILD 20:09:52 Nov  4 2020
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0
	/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/
ld: warning: static initializer found in '/var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//cccaMqmZ.o'. Use -no_inits to make this an error.  Use -no_warn_inits to suppress warning
ld: warning: invalid -install_name (/usr/local/lib/gcc/10/libgcc_s.1.dylib) in dependent dylib (/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/libgcc_ext.10.5.dylib). Dylibs/frameworks which might go in dyld shared cache cannot link with dylibs that won't be in the shared cache
ld: warning: linking with (/usr/local/lib/gcc/10/libgcc_s.1.dylib) but not using any symbols from it
```

Now we can verify using otool that the dylib ID is correctly set:

```
$ otool
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool [-arch arch_type] [-fahlLDtdorSTMRIHGvVcXmqQjCP] [-mcpu=arg] [--version] <object file> ...
	-f print the fat headers
	-a print the archive header
	-h print the mach header
	-l print the load commands
	-L print shared libraries used
	-D print shared library id name.                          <—— This option is used to print the dylib ID
	-t print the text section (disassemble with -v)
	-x print all text sections (disassemble with -v)
	-p <routine name>  start dissassemble from routine name
	-s <segname> <sectname> print contents of section
	-d print the data section
	-o print the Objective-C segment
	-r print the relocation entries
	-S print the table of contents of a library (obsolete)
	-T print the table of contents of a dynamic shared library (obsolete)
	-M print the module table of a dynamic shared library (obsolete)
	-R print the reference table of a dynamic shared library (obsolete)
	-I print the indirect symbol table
	-H print the two-level hints table (obsolete)
	-G print the data in code table
	-v print verbosely (symbolically) when possible
	-V print disassembled operands symbolically
	-c print argument strings of a core file
	-X print no leading addresses or headers
	-m don't use archive(member) syntax
	-B force Thumb disassembly (ARM objects only)
	-q use llvm's disassembler (the default)
	-Q use otool(1)'s disassembler
	-mcpu=arg use `arg' as the cpu for disassembly
	-j print opcode bytes
	-P print the info plist section as strings
	-C print linker optimization hints
	--version print the version of /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
```

The dylib ID is correctly set:

```
$ otool -D ratings.dylib
ratings.dylib:
/usr/lib/ratings.dylib
```

Thanks for the help,
Davide


> On 17 Jan 2021, at 13:36, akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
> 
> "davide.restivo--- via \"Bug reports for GNU Emacs, the Swiss army knife
> of text editors\"" <bug-gnu-emacs@gnu.org> writes:
> 
> [...]
> 
>> Since the tmp directory is stripped out and replaced with the
>> destination directory, as you can see, all of the ELN files ends up with
>> the same dylib ID, and this is not allowed on macOS. My suggestion here
>> would be to add the 'install_name' [2] flag to gcc during the ELN files
>> compilation replacing the 'fake.so' with the original .eln filename.
>> 
>> Thanks and regards,
>> Davide
>> 
>> 
>> [1] https://github.com/daviderestivo/homebrew-emacs-head
>> [2] gcc -o libdummy.dylib -install_name ${PREFIX}/lib/libdummy.dylib 
> 
> Hi Davide,
> 
> I'm really ignorant on MacOS so I'll comment for what I can.  I had a
> look to the GCC doc [1] but I could not figure out if '-install_name' is
> an option that goes to the compiler or the linker (nor I know what this
> dylib ID exactly is).  If the flag is routed to the linker we should be
> able to add it but only when libgccjit >= 9 is used.
> 
> Could you run a random compilation of something using '-install_name'
> but adding also '-v' and report the console output so we can see where
> the driver is routing the flag?
> 
> Thanks
> 
>  Andrea
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Darwin-Options.html
> 
> 
> 

bug#45934: native-comp - Dylib ID of ELN files not optimal

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"davide.restivo--- via \"Bug reports for GNU Emacs, the Swiss army knife
of text editors\"" <bug-gnu-emacs@gnu.org> writes:

> Hi Andrea,
>
> A dylib (extension .dylib) is the same as a GNU/Linux shared object (extension .so). Please find below the requested output:

Ciao Davide,

yes my question was on what the dylib ID is and what's is purpose.

> ```
> $ /usr/local/bin/gcc-10 --version
> gcc-10 (Homebrew GCC 10.2.0_2) 10.2.0
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[...]

> /usr/bin/ld -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/ -dynamic -dylib -arch x86_64 -dylib_install_name /usr/lib/ratings.dylib -macosx_version_min 10.15.0 -weak_reference_mismatches non-weak -o ratings.dylib -L/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../.. /var/folders/r4/5c0t6dm912vggdd3jbjf_3tr0000gn/T//cccaMqmZ.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v

Okay, we should be able to work it around but as anticipated only using
GCC >= 9, that is indeed not very satisfactory.

My question is: if is homebrew the owner of this build process shouldn't
be its responsibility to keep the ID unique?

How do you work around this issue now?

Thanks

  Andrea

bug#45934: native-comp - Dylib ID of ELN files not optimal

[davide.restivo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ciao Andrea,

Please find below inline my answers. Sorry for the late reply :).

Regards,
Davide


> yes my question was on what the dylib ID is and what's is purpose.

A `dylib ID` a.k.a. `install_name` is the unique identifier that a library
provides to an executable that links against it. Once an executable
links against a library, the install_name values is stored in the linking
application and used at runtime to find the .dylib location.

Very important is that there cannot be, as far as I understood, two .dylib
loaded at the same time with the same dylib ID. I guess this was the
reason for the strange behaviour (unmapped .eln) we discussed
some time ago [1].

> Okay, we should be able to work it around but as anticipated only using
> GCC >= 9, that is indeed not very satisfactory.

Maybe you could conditionally enable the `install_name` support only if GCC >=9.
I will add a dependency in my Homebrew GNU/Emacs Formula to GCC-10, that
is anyway the Homebrew default.


> My question is: if is homebrew the owner of this build process shouldn't
> be its responsibility to keep the ID unique?

Unfortunately this is not the case since Homebrew simply change the dylib ID
basepath from `sandbox` to `installation directory`. I have already opened an
‘issue’ to homebrew core developers but they suggested to properly set the
install_name. Please see [2] and [3] for more insights.


> How do you work around this issue now?


What I have implemented as a workaround is the replacing of the original dylib ID
i.e. /private/tmp/libgccjit-3AyZly/fake.so with  <sandbox_path>/<filename>.eln.

Below the ruby code snippet.

```
        # Change .eln files dylib ID to avoid that after the
        # post-install phase all of the *.eln files end up with the
        # same ID. See: https://github.com/Homebrew/brew/issues/9526
        # and https://github.com/Homebrew/brew/pull/10075
        Dir.glob(contents_dir/"native-lisp/*/*.eln").each do |f|
          fo = MachO::MachOFile.new(f)
          ohai "Change dylib_id of ELN files before post_install phase"
          fo.dylib_id = "#{contents_dir}/" + f
          fo.write!
        end
      end
```


[1] https://github.com/daviderestivo/homebrew-emacs-head/issues/23#issuecomment-695175926
[2] https://github.com/Homebrew/brew/issues/9526
[3] https://github.com/Homebrew/brew/pull/10075

bug#45934: native-comp - Dylib ID of ELN files not optimal

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Davide Restivo <davide.restivo@yahoo.it> writes:

> Ciao Andrea,
>
> Please find below inline my answers. Sorry for the late reply :).
>
> Regards,
> Davide
>
>
>> yes my question was on what the dylib ID is and what's is purpose.
>
> A `dylib ID` a.k.a. `install_name` is the unique identifier that a library
> provides to an executable that links against it. Once an executable
> links against a library, the install_name values is stored in the linking
> application and used at runtime to find the .dylib location.
>
> Very important is that there cannot be, as far as I understood, two .dylib
> loaded at the same time with the same dylib ID. I guess this was the
> reason for the strange behaviour (unmapped .eln) we discussed
> some time ago [1].
>
>> Okay, we should be able to work it around but as anticipated only using
>> GCC >= 9, that is indeed not very satisfactory.
>
> Maybe you could conditionally enable the `install_name` support only if GCC >=9.
> I will add a dependency in my Homebrew GNU/Emacs Formula to GCC-10, that
> is anyway the Homebrew default.

Ciao Davide,

SGTM, I'll try to come-up with patch.

  Andrea

bug#45934: native-comp - Dylib ID of ELN files not optimal

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

Ciao Davide,

could you give it a try with the following blind patch? (can't test it
my-self).

Thanks

  Andrea


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-On-MacOS-set-a-unique-dylib-ID-Bug-45934.patch --]
[-- Type: text/x-diff, Size: 1130 bytes --]

From c4990edcea51e273452e13a4b9b98549aa62a508 Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@sdf.org>
Date: Thu, 28 Jan 2021 22:54:49 +0100
Subject: [PATCH] * On MacOS set a unique dylib ID (Bug#45934)

	* src/comp.c (Fcomp__compile_ctxt_to_file): On MacOS set a unique
	dylib ID (Bug#45934).
---
 src/comp.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/src/comp.c b/src/comp.c
index b5adc3ed86..d959c3188c 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -4374,6 +4374,16 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file,
 				  GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL,
 				  comp.speed < 0 ? 0
 				  : (comp.speed > 3 ? 3 : comp.speed));
+
+/* On MacOS set a unique dylib ID (Bug#45934). */
+#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option) \
+  && defined (DARWIN_OS)
+  gcc_jit_context_add_driver_option (
+    comp.ctxt,
+    SSDATA (concat2 (build_string ("-install_name "),
+		     Ffile_name_nondirectory (filename))));
+#endif
+
   comp.d_default_idx =
     CALL1I (comp-data-container-idx, CALL1I (comp-ctxt-d-default, Vcomp_ctxt));
   comp.d_impure_idx =
-- 
2.20.1

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Eli Zaretskii]

> Date: Thu, 28 Jan 2021 21:59:16 +0000
> Cc: 45934@debbugs.gnu.org
> From: akrl--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> +/* On MacOS set a unique dylib ID (Bug#45934). */
> +#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option) \
> +  && defined (DARWIN_OS)
> +  gcc_jit_context_add_driver_option (
> +    comp.ctxt,
> +    SSDATA (concat2 (build_string ("-install_name "),
> +		     Ffile_name_nondirectory (filename))));
> +#endif

A minor nit unrelated to the issue at hand: if you take care to
mention the bug number in the commit log message, there's no need to
do that in the comments.

In general, I don't think it's a good idea to have our sources full of
references to bug reports; if the comment by itself doesn't explain
the underlying issue, it is better to enhance the comment to be
self-contained.  IMO, a reference to a bug in the comments is only
justified when the issue is so complicated to explain that having such
an explanation in comments is impractical.

TIA

bug#45934: native-comp - Dylib ID of ELN files not optimal

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 28 Jan 2021 21:59:16 +0000
>> Cc: 45934@debbugs.gnu.org
>> From: akrl--- via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> +/* On MacOS set a unique dylib ID (Bug#45934). */
>> +#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option) \
>> +  && defined (DARWIN_OS)
>> +  gcc_jit_context_add_driver_option (
>> +    comp.ctxt,
>> +    SSDATA (concat2 (build_string ("-install_name "),
>> +		     Ffile_name_nondirectory (filename))));
>> +#endif
>
> A minor nit unrelated to the issue at hand: if you take care to
> mention the bug number in the commit log message, there's no need to
> do that in the comments.
>
> In general, I don't think it's a good idea to have our sources full of
> references to bug reports; if the comment by itself doesn't explain
> the underlying issue, it is better to enhance the comment to be
> self-contained.  IMO, a reference to a bug in the comments is only
> justified when the issue is so complicated to explain that having such
> an explanation in comments is impractical.
>
> TIA

SGTM, I'll update the patch at the next iteration or before pushing it.

Thanks

  Andrea

bug#45934: native-comp - Dylib ID of ELN files not optimal

[davide.restivo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Andrea,

Thanks, I will make some tests and come back to you asap.

Regards,
Davide


> On 28 Jan 2021, at 22:59, akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
> 
> Ciao Davide,
> 
> could you give it a try with the following blind patch? (can't test it
> my-self).
> 
> Thanks

bug#45934: native-comp - Dylib ID of ELN files not optimal

[xgutter--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ciao Andrea,

It took a bit long to find some time to test your patch, sorry for this. I slightly changed your patch adding `-dynamiclib` before `-install-name` otherwise I was getting an error.

```
SSDATA (concat2 (build_string ("-dynamiclib -install_name "),
```

Even with this change the Dylib ID of the ELN files is not changed. See below:


```
otool -D native-lisp/28.0.50-x86_64-apple-darwin19.6.0-a6e4783a5ef98abfce43023b5021c5a0/x-win-3c49581f605e9300257e9a0c4594695d-57571c2341c5223f94e6710bc3fe737f.eln
native-lisp/28.0.50-x86_64-apple-darwin19.6.0-a6e4783a5ef98abfce43023b5021c5a0/x-win-3c49581f605e9300257e9a0c4594695d-57571c2341c5223f94e6710bc3fe737f.eln:
/var/folders/77/680fcz1x5ydb0r8f93kj36b0wws01s/T//libgccjit-7kfo57/fake.so
```

Regards,
Davide


> On 30 Jan 2021, at 09:18, davide.restivo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
> 
> Hi Andrea,
> 
> Thanks, I will make some tests and come back to you asap.
> 
> Regards,
> Davide
> 
> 
>> On 28 Jan 2021, at 22:59, akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
>> 
>> Ciao Davide,
>> 
>> could you give it a try with the following blind patch? (can't test it
>> my-self).
>> 
>> Thanks
> 
> 
> 
> 

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

xgutter@yahoo.it writes:

> It took a bit long to find some time to test your patch, sorry for
> this. I slightly changed your patch adding `-dynamiclib` before
> `-install-name` otherwise I was getting an error.
>
> ```
> SSDATA (concat2 (build_string ("-dynamiclib -install_name "),
> ```
>
> Even with this change the Dylib ID of the ELN files is not changed. See below:
>
> ```
> otool -D
> native-lisp/28.0.50-x86_64-apple-darwin19.6.0-a6e4783a5ef98abfce43023b5021c5a0/x-win-3c49581f605e9300257e9a0c4594695d-57571c2341c5223f94e6710bc3fe737f.eln
> native-lisp/28.0.50-x86_64-apple-darwin19.6.0-a6e4783a5ef98abfce43023b5021c5a0/x-win-3c49581f605e9300257e9a0c4594695d-57571c2341c5223f94e6710bc3fe737f.eln:
> /var/folders/77/680fcz1x5ydb0r8f93kj36b0wws01s/T//libgccjit-7kfo57/fake.so
> ```

This was half a year ago -- has there been any progress in fixing this
Macos-specific issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> xgutter@yahoo.it writes:
>
>> It took a bit long to find some time to test your patch, sorry for
>> this. I slightly changed your patch adding `-dynamiclib` before
>> `-install-name` otherwise I was getting an error.
>>
>> ```
>> SSDATA (concat2 (build_string ("-dynamiclib -install_name "),
>> ```
>>
>> Even with this change the Dylib ID of the ELN files is not changed. See below:
>>
>> ```
>> otool -D
>> native-lisp/28.0.50-x86_64-apple-darwin19.6.0-a6e4783a5ef98abfce43023b5021c5a0/x-win-3c49581f605e9300257e9a0c4594695d-57571c2341c5223f94e6710bc3fe737f.eln
>> native-lisp/28.0.50-x86_64-apple-darwin19.6.0-a6e4783a5ef98abfce43023b5021c5a0/x-win-3c49581f605e9300257e9a0c4594695d-57571c2341c5223f94e6710bc3fe737f.eln:
>> /var/folders/77/680fcz1x5ydb0r8f93kj36b0wws01s/T//libgccjit-7kfo57/fake.so
>> ```
>
> This was half a year ago -- has there been any progress in fixing this
> Macos-specific issue?

Not on my side.  I cannot experiment as I've no Mac machines but I
believe that if "-dynamiclib -install_name" are not working as expected
it should be reported on the toolchain side.  Otherwise there's not much
we can do on the Emacs side.

BR

  Andrea

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> Not on my side.  I cannot experiment as I've no Mac machines but I
> believe that if "-dynamiclib -install_name" are not working as expected
> it should be reported on the toolchain side.  Otherwise there's not much
> we can do on the Emacs side.

I've got a Mac machine, and I tried briefly to get nativecomp to work so
that I could test it, but no go.

Does anybody have a recipe for how to build Emacs with nativecomp on
Macos (preferably with Macports)?  (I tried googling, but...  I found
people maintaining huge Python scripts to build Emacs, which I hope
isn't necessary.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Alan Third]

On Wed, Aug 04, 2021 at 08:55:48AM +0200, Lars Ingebrigtsen wrote:
> Andrea Corallo <akrl@sdf.org> writes:
> 
> > Not on my side.  I cannot experiment as I've no Mac machines but I
> > believe that if "-dynamiclib -install_name" are not working as expected
> > it should be reported on the toolchain side.  Otherwise there's not much
> > we can do on the Emacs side.
> 
> I've got a Mac machine, and I tried briefly to get nativecomp to work so
> that I could test it, but no go.
> 
> Does anybody have a recipe for how to build Emacs with nativecomp on
> Macos (preferably with Macports)?  (I tried googling, but...  I found
> people maintaining huge Python scripts to build Emacs, which I hope
> isn't necessary.)

I'm not sure about with MacPorts, but with Homebrew it should just be
a case of installing libgccjit and configuring as normal.

If it's an Arm mac then I think it requires gcc 11.

I don't know why the Mac community tends towards maintaining huge
scripts and/or lists of configure flags for building Emacs, because in
my experience they're not required, but it does seem to be the norm.

FWIW, I don't know what the original bug report is really about. I'm
guessing it's to do with making an app bundle that can be copied to
other machines or something? That's always a problem.
-- 
Alan Third

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> I'm not sure about with MacPorts, but with Homebrew it should just be
> a case of installing libgccjit and configuring as normal.

With Macports, Configuring as normal just gets me clang (masquerading as
/usr/bin/cc), but I can say "CC=/that/macports/gcc ./configure", but it
doesn't find the libgccjit stuff.

> If it's an Arm mac then I think it requires gcc 11.
>
> I don't know why the Mac community tends towards maintaining huge
> scripts and/or lists of configure flags for building Emacs, because in
> my experience they're not required, but it does seem to be the norm.

Yeah, building on Macos is almost as trivial as on Debian (at least with
clang), but there's all these really convoluted scripts out there...

My hope was that it was as simple to build with the Macports gcc, too,
but...  apparently not?  (I'd rather not install Homebrew, too, on this
laptop -- that just sounds too confusing.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Alan Third]

On Thu, Aug 05, 2021 at 12:54:09PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > I'm not sure about with MacPorts, but with Homebrew it should just be
> > a case of installing libgccjit and configuring as normal.
> 
> With Macports, Configuring as normal just gets me clang (masquerading as
> /usr/bin/cc), but I can say "CC=/that/macports/gcc ./configure", but it
> doesn't find the libgccjit stuff.

You don't need to build with gcc to use libgccjit, and in fact you
can't build the GUI with gcc at all.

I finally found the code that works it out for Homebrew. I've never
used MacPorts but I think all you need to do is something similar to
(from configure.ac:3820):

    CFLAGS="$CFLAGS -I${BREW_LIBGCCJIT_PREFIX}/include"
    LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"

Where "${BREW_LIBGCCJIT_PREFIX}/include" is where the include files
are and ${brew_libdir} is where the .so files are.

This is relatively easy to automate with Homebrew because we can just
ask it where libgccjit is installed and then work out the paths, but
I don't know about Macports.

> > If it's an Arm mac then I think it requires gcc 11.
> >
> > I don't know why the Mac community tends towards maintaining huge
> > scripts and/or lists of configure flags for building Emacs, because in
> > my experience they're not required, but it does seem to be the norm.
> 
> Yeah, building on Macos is almost as trivial as on Debian (at least with
> clang), but there's all these really convoluted scripts out there...
> 
> My hope was that it was as simple to build with the Macports gcc, too,
> but...  apparently not?  (I'd rather not install Homebrew, too, on this
> laptop -- that just sounds too confusing.)

I'm sure it must be easy enough. Homebrew is a bit of a pain in the
backside because it intentionally leaves many installed packages
unavailable so as not to interfere with the normal macOS install. I
was under the impression that Macports was a simpler set-up.
-- 
Alan Third

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Alan Third <alan@idiocy.org> writes:

> I finally found the code that works it out for Homebrew. I've never
> used MacPorts but I think all you need to do is something similar to
> (from configure.ac:3820):
>
>     CFLAGS="$CFLAGS -I${BREW_LIBGCCJIT_PREFIX}/include"
>     LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
>
> Where "${BREW_LIBGCCJIT_PREFIX}/include" is where the include files
> are and ${brew_libdir} is where the .so files are.

Ah, thanks.  With that I was able to cobble together a patch to make it
compile under Macos with Macports, but it obviously needs more work
before pushing.  I'm not really familiar with the "port" command at all
-- can I get it to cough up which gcc version is installed, for
instance?

I'll poke around some more and clean up the patch.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

[-- Attachment #2: jit --]
[-- Type: application/octet-stream, Size: 3565 bytes --]

diff --git a/configure.ac b/configure.ac
index 79cc56f9a7..cb5f4b58ac 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1334,6 +1334,9 @@ AC_DEFUN
     [`$BREW --prefix texinfo 2>/dev/null`/bin$PATH_SEPARATOR$PATH])
 fi
 
+# Check MacPorts on macOS.
+AC_PATH_PROG(HAVE_MACPORTS, port)
+
 ## Require makeinfo >= 4.13 (last of the 4.x series) to build the manuals.
 : ${MAKEINFO:=makeinfo}
 case `($MAKEINFO --version) 2>/dev/null` in
@@ -3807,7 +3810,8 @@ AC_DEFUN
 <https://gcc.gnu.org/wiki/JIT>.])])
 
 HAVE_NATIVE_COMP=no
-LIBGCCJIT_LIB=
+LIBGCCJIT_LIBS=
+LIBGCCJIT_CFLAGS=
 if test "${with_native_compilation}" != "no"; then
     if test "${HAVE_PDUMPER}" = no; then
        AC_MSG_ERROR(['--with-nativecomp' requires '--with-dumping=pdumper'])
@@ -3827,6 +3831,13 @@ AC_DEFUN
       fi
     fi
 
+    # Ensure libgccjit installed by MacPorts can be found.
+    if test -n "$HAVE_MACPORTS"; then
+      CPPFLAGS="$CPPFLAGS -I/opt/local/include/gcc11"
+      CFLAGS="$CFLAGS -I/opt/local/include/gcc11"
+      LDFLAGS="$LDFLAGS -L/opt/local/lib/gcc11 -I/opt/local/include/gcc11"
+    fi
+
     # Check if libgccjit is available.
     AC_CHECK_LIB(gccjit, gcc_jit_context_acquire, [], [libgccjit_not_found])
     AC_CHECK_HEADERS(libgccjit.h, [], [libgccjit_dev_not_found])
@@ -3841,17 +3852,24 @@ AC_DEFUN
       mingw32) ;;
       # OpenBSD doesn't have libdl, all the functions are in libc
       netbsd|openbsd)
-        LIBGCCJIT_LIB="-lgccjit" ;;
+        LIBGCCJIT_LIBS="-lgccjit" ;;
       *)
-        LIBGCCJIT_LIB="-lgccjit -ldl" ;;
+        LIBGCCJIT_LIBS="-lgccjit -ldl" ;;
     esac
     NEED_DYNLIB=yes
     AC_DEFINE(HAVE_NATIVE_COMP, 1, [Define to 1 if native compiler is available.])
+    
+    # Ensure libgccjit installed by MacPorts can be found.
+    if test -n "$HAVE_MACPORTS"; then
+      LIBGCCJIT_CFLAGS="$LIBGCCJIT_CFLAGS -I/opt/local/include/gcc11"
+      LIBGCCJIT_LIBS="-L/opt/local/lib/gcc11 $LIBGCCJIT_LIBS"
+    fi
 fi
 AC_DEFINE_UNQUOTED(NATIVE_ELISP_SUFFIX, ".eln",
   [System extension for native compiled elisp])
 AC_SUBST(HAVE_NATIVE_COMP)
-AC_SUBST(LIBGCCJIT_LIB)
+AC_SUBST(LIBGCCJIT_CFLAGS)
+AC_SUBST(LIBGCCJIT_LIBS)
 
 DYNLIB_OBJ=
 if test "${NEED_DYNLIB}" = yes; then
diff --git a/src/Makefile.in b/src/Makefile.in
index 22c7aeed5c..732cd8f099 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -326,7 +326,8 @@ GETLOADAVG_LIBS =
 
 LIBGMP = @LIBGMP@
 
-LIBGCCJIT = @LIBGCCJIT_LIB@
+LIBGCCJIT_LIBS = @LIBGCCJIT_LIBS@
+LIBGCCJIT_CFLAGS = @LIBGCCJIT_CFLAGS@
 
 ## dynlib.o if necessary, else empty
 DYNLIB_OBJ = @DYNLIB_OBJ@
@@ -367,7 +368,7 @@ EMACS_CFLAGS=
   -I$(lib) -I$(top_srcdir)/lib \
   $(C_SWITCH_MACHINE) $(C_SWITCH_SYSTEM) $(C_SWITCH_X_SITE) \
   $(GNUSTEP_CFLAGS) $(CFLAGS_SOUND) $(RSVG_CFLAGS) $(IMAGEMAGICK_CFLAGS) \
-  $(PNG_CFLAGS) $(LIBXML2_CFLAGS) $(DBUS_CFLAGS) \
+  $(PNG_CFLAGS) $(LIBXML2_CFLAGS) $(LIBGCCJIT_CFLAGS) $(DBUS_CFLAGS) \
   $(XRANDR_CFLAGS) $(XINERAMA_CFLAGS) $(XFIXES_CFLAGS) $(XDBE_CFLAGS) \
   $(WEBKIT_CFLAGS) $(LCMS2_CFLAGS) \
   $(SETTINGS_CFLAGS) $(FREETYPE_CFLAGS) $(FONTCONFIG_CFLAGS) \
@@ -516,7 +517,7 @@ LIBES =
    $(FREETYPE_LIBS) $(FONTCONFIG_LIBS) $(HARFBUZZ_LIBS) $(LIBOTF_LIBS) $(M17N_FLT_LIBS) \
    $(LIBGNUTLS_LIBS) $(LIB_PTHREAD) $(GETADDRINFO_A_LIBS) $(LCMS2_LIBS) \
    $(NOTIFY_LIBS) $(LIB_MATH) $(LIBZ) $(LIBMODULES) $(LIBSYSTEMD_LIBS) \
-   $(JSON_LIBS) $(LIBGMP) $(LIBGCCJIT)
+   $(JSON_LIBS) $(LIBGMP) $(LIBGCCJIT_LIBS)
 
 ## FORCE it so that admin/unidata can decide whether this file is
 ## up-to-date.  Although since charprop depends on bootstrap-emacs,

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Alan Third]

On Fri, Aug 06, 2021 at 12:49:39PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > I finally found the code that works it out for Homebrew. I've never
> > used MacPorts but I think all you need to do is something similar to
> > (from configure.ac:3820):
> >
> >     CFLAGS="$CFLAGS -I${BREW_LIBGCCJIT_PREFIX}/include"
> >     LDFLAGS="$LDFLAGS -L${brew_libdir} -I${BREW_LIBGCCJIT_PREFIX}/include"
> >
> > Where "${BREW_LIBGCCJIT_PREFIX}/include" is where the include files
> > are and ${brew_libdir} is where the .so files are.
> 
> Ah, thanks.  With that I was able to cobble together a patch to make it
> compile under Macos with Macports, but it obviously needs more work
> before pushing.  I'm not really familiar with the "port" command at all
> -- can I get it to cough up which gcc version is installed, for
> instance?

If you look at the line just above the CFLAGS one in configure.ac
there's a horrible little find/sed script that I had to come up with
to work out the path to the lib directory because homebrew sticks them
in a directory named 10 or 11 or whatever depending on the version of
gcc. Perhaps it can be generalised for Macports too?

-- 
Alan Third

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> If you look at the line just above the CFLAGS one in configure.ac
> there's a horrible little find/sed script that I had to come up with
> to work out the path to the lib directory because homebrew sticks them
> in a directory named 10 or 11 or whatever depending on the version of
> gcc. Perhaps it can be generalised for Macports too?

I poked around more with the "port" command, and it's pretty good --
with a bit of mangling of the output, I was able to get at the
information required.  So I'm now pushing the conf changes for Macports.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I poked around more with the "port" command, and it's pretty good --
> with a bit of mangling of the output, I was able to get at the
> information required.  So I'm now pushing the conf changes for Macports.

Oh, and if you could check that I didn't break something in the homebrew
case, that'd be great.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

OK, back to the ostensible subject of this bug report.

This is what the current trunk currently gives us:

bash-3.2$ otool -D native-lisp/28_0_50-395a4a99/preloaded/x-win-3c49581f-3fe8af32.eln 
native-lisp/28_0_50-395a4a99/preloaded/x-win-3c49581f-3fe8af32.eln:
/var/folders/09/qpnlh75n3t70kt9dcw8jlqb80000gn/T//libgccjit-BikCmL/fake.so

And with Andrea's patch it...  er...  segfaults...

Let's try a "make bootstrap" and see whether that helps.  ... Yup, now
it compiles fine.

And:

bash-3.2$ otool -D native-lisp/28_0_50-395a4a99/preloaded/x-win-3c49581f-3fe8af32.eln 
native-lisp/28_0_50-395a4a99/preloaded/x-win-3c49581f-3fe8af32.eln:
/var/folders/09/qpnlh75n3t70kt9dcw8jlqb80000gn/T//libgccjit-Lge08S/fake.so

So...  it had no effect?  This was the patch I applied:

diff --git a/src/comp.c b/src/comp.c                                            
index c380346482..6347c015cd 100644                                             
--- a/src/comp.c                                                                
+++ b/src/comp.c                                                                
@@ -4490,6 +4490,16 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt\
_to_file,                                                                       
                                  GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL,        
                                  comp.speed < 0 ? 0                            
                                  : (comp.speed > 3 ? 3 : comp.speed));         
+                                                                               
+/* On MacOS set a unique dylib ID (Bug#45934). */                              
+#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option) \               
+  && defined (DARWIN_OS)                                                       
+  gcc_jit_context_add_driver_option (                                          
+    comp.ctxt,                                                                 
+    SSDATA (concat2 (build_string ("-dynamiclib -install_name "),              
+                    Ffile_name_nondirectory (filename))));                     
+#endif                                                                         
+                                                                               
   comp.d_default_idx =                                                         
     CALL1I (comp-data-container-idx, CALL1I (comp-ctxt-d-default, Vcomp_ctxt))\
;                                                                               
   comp.d_impure_idx =                                                          



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Alan Third]

On Sat, Aug 07, 2021 at 12:25:02PM +0200, Lars Ingebrigtsen wrote:
> So...  it had no effect?  This was the patch I applied:

Looks like the function only takes one string at a time, so this seems
to work here:

@@ -4490,6 +4490,15 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file,
 				  GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL,
 				  comp.speed < 0 ? 0
 				  : (comp.speed > 3 ? 3 : comp.speed));
+
+  /* On MacOS set a unique dylib ID (Bug#45934). */
+#if defined (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option) \
+  && defined (DARWIN_OS)
+  gcc_jit_context_add_driver_option (comp.ctxt, "-install_name");
+  gcc_jit_context_add_driver_option (
+	  comp.ctxt, SSDATA (Ffile_name_nondirectory (filename)));
+#endif
+
   comp.d_default_idx =
     CALL1I (comp-data-container-idx, CALL1I (comp-ctxt-d-default, Vcomp_ctxt));
   comp.d_impure_idx =

-- 
Alan Third

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> On Sat, Aug 07, 2021 at 12:25:02PM +0200, Lars Ingebrigtsen wrote:
>> So...  it had no effect?  This was the patch I applied:
>
> Looks like the function only takes one string at a time, so this seems
> to work here:

Ah, I see.  David, can you try this patch and see whether it fixes the
problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Davide Restivo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Lars,

I’m back in business after holidays. Thanks a lot for coming up with a new patch. I’ll try it out and come back to you asap.

Regards,
Davide 


> On 9 Aug 2021, at 14:20, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Alan Third <alan@idiocy.org> writes:
> 
>> On Sat, Aug 07, 2021 at 12:25:02PM +0200, Lars Ingebrigtsen wrote:
>>> So...  it had no effect?  This was the patch I applied:
>> 
>> Looks like the function only takes one string at a time, so this seems
>> to work here:
> 
> Ah, I see.  David, can you try this patch and see whether it fixes the
> problem?
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no
> 
> 
> 

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Davide Restivo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Lars,

The patch seems to work fine. Here [1] the succesful outcome of my GitHub CI.

@Alan: thanks a lot for your help.


Regards,
Davide


[1] https://github.com/daviderestivo/homebrew-emacs-head/runs/3394589191


> On 22 Aug 2021, at 19:18, Davide Restivo via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
> 
> Hi Lars,
> 
> I’m back in business after holidays. Thanks a lot for coming up with a new patch. I’ll try it out and come back to you asap.
> 
> Regards,
> Davide 
> 
> 
>> On 9 Aug 2021, at 14:20, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> 
>> Alan Third <alan@idiocy.org> writes:
>> 
>>> On Sat, Aug 07, 2021 at 12:25:02PM +0200, Lars Ingebrigtsen wrote:
>>>> So...  it had no effect?  This was the patch I applied:
>>> 
>>> Looks like the function only takes one string at a time, so this seems
>>> to work here:
>> 
>> Ah, I see.  David, can you try this patch and see whether it fixes the
>> problem?
>> 
>> -- 
>> (domestic pets only, the antidote for overdose, milk.)
>>  bloggy blog: http://lars.ingebrigtsen.no
>> 
>> 
>> 
> 
> 
> 
> 

bug#45934: native-comp - Dylib ID of ELN files not optimal

[Alan Third]

On Sun, Aug 22, 2021 at 09:40:20PM +0200, Davide Restivo wrote:
> Hi Lars,
> 
> The patch seems to work fine. Here [1] the succesful outcome of my GitHub CI.
> 
> @Alan: thanks a lot for your help.

Thanks, I've pushed it to master as 6c007668b38f06824004da466e97a96533f6344b.

-- 
Alan Third