On Wed, Jan 29, 2025 at 4:35 PM Marc Culler <marc.cul...@gmail.com> wrote:
>
> Looking back at the failed command I actually think this is a clang bug which
> has nothing to do with GAP. The relevant option is:
> -bundle_loader /private/var/tmp/sage-10.6-current/local/bin/gap
> I think that option is broken in the latest clang.
> I think that option means that the linker should not complain about a missing
> symbol if that symbol is defined in the executable which loads the library,
> or in any library loaded by that executable. In the case of local/bin/gap I
> see that (of course) it loads libgap:
Why does it load libgap? That's a bug in the gap's building by Sage I
think (no idea how it happens though).
Out of the Sage tree build has the following linkage; see - no libgap linked.
% otool -L gap
gap:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1351.0.0)
/opt/homebrew/opt/gmp/lib/libgmp.10.dylib (compatibility
version 16.0.0, current version 16.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.12)
/opt/homebrew/opt/readline/lib/libreadline.8.dylib
(compatibility version 8.2.0, current version 8.2.0)
as opposed to Sage's build:
% otool -L sage/local/bin/gap
sage/local/bin/gap:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1351.0.0)
/opt/homebrew/opt/gmp/lib/libgmp.10.dylib (compatibility
version 16.0.0, current version 16.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.12)
/opt/homebrew/opt/readline/lib/libreadline.8.dylib
(compatibility version 8.2.0, current version 8.2.0)
/Volumes/dima/sage/local/lib/libgap.9.dylib (compatibility
version 10.0.0, current version 10.0.0)
Dima
> LC_LOAD_DYLIB: /usr/lib/libSystem.B.dylib
> LC_LOAD_DYLIB: @rpath/libgmp.10.dylib
> LC_LOAD_DYLIB: @rpath/libz.1.dylib
> LC_LOAD_DYLIB: @rpath/libreadline.8.dylib
> LC_LOAD_DYLIB: @rpath/libgap.9.dylib
> So the linker should not have complained about those missing symbols, much
> less have raised an error. And, in fact, there was no error on my Intel
> system with an older clang. However, I think that linking against libgap
> accomplishes the same thing, It lets the linker know that the symbol will
> exist when the crypting library is loaded. So I don't think that is a bad
> workaround, and I think it will not be necessary after the next release of
> XCode. GAP is doing nothing wrong, except to assume that the -bundle-loader
> option will work as advertised.
>
> - Marc.
>
> On Wed, Jan 29, 2025 at 3:21 PM Dima Pasechnik <dimp...@gmail.com> wrote:
>>
>>
>>
>> On 29 January 2025 14:43:17 GMT-06:00, Marc Culler <marc.cul...@gmail.com>
>> wrote:
>> >On Wed, Jan 29, 2025 at 1:33 PM Dima Pasechnik <dimp...@gmail.com> wrote:
>> >
>> >>
>> >> libgap is not really involved here;
>> >>
>> >cypring's GAP kernel module
>> >> (that's what's compiled here) can be loaded either in libgap, or in
>> >> gap executable - and the latter
>> >> isn't linked to libgap.
>> >
>> >
>> >I am no expert in GAP. But the code in crypting.c references symbols which
>> >are defined in libgap. So to build crypting.so from crypting.o you have to
>> >link against libgap or something else which defines those same symbols.
>>
>> GAP does dynamic symbol resolution when it loads an extension module.
>> On macOS, GAP does not link libgap; one can check with "otool -L".
>>
>> libgap does contain the internal symbols needed for kernel extension
>> modules available in GAP the executable, and is equally able to load a GAP
>> kernel extension module.
>>
>> If you link a GAP kernel module to libgap, and load it into GAP, the latter
>> will also load libgap, and the hell can potentially break loose.
>> Even if it doesn't, an extra unneeded library would be loaded.
>>
>> crypting.so, the GAP kernel extension module, normally only links to a macOS
>> system library, and nothing else.
>>
>> Dima
>>
>> >After building with my patch, if I run the gap executable
>> >$SAGE_ROOT/local/bin/gap then I am able to load the crypting module:
>> >
>> >%
>> >/Applications/SageMath-10-6.app/Contents/Frameworks/Sage.framework/Versions/Current/local/bin/gap
>> > ┌───────┐ GAP 4.13.1 of 2024-06-11
>> > │ GAP │ https://www.gap-system.org
>> > └───────┘ Architecture: aarch64-apple-darwin24-default64-kv9
>> > Configuration: gmp 6.3.0, GASMAN, readline
>> > Loading the library and packages ...
>> > Packages: AClib 1.3.2, Alnuth 3.2.1, AtlasRep 2.1.8, AutPGrp 1.11,
>> > CRISP 1.4.6, Cryst 4.1.27, CrystCat 1.1.10, CTblLib 1.3.9,
>> > FactInt 1.6.3, FGA 1.5.0, GAPDoc 1.6.7, IO 4.8.2,
>> > IRREDSOL 1.4.4, LAGUNA 3.9.6, Polenta 1.3.10, Polycyclic 2.16,
>> > PrimGrp 3.4.4, RadiRoot 2.9, ResClasses 4.7.3, SmallGrp 1.5.3,
>> > Sophus 1.27, TomLib 1.2.11, TransGrp 3.6.5, utils 0.85
>> > Try '??help' for help. See also '?copyright', '?cite' and '?authors'
>> >gap> LoadPackage("crypting");
>> >────────────────────────────────────────────────────────────────────────────
>> >Loading crypting 0.10.4 (Hashes and Crypto in GAP)
>> >by Markus Pfeiffer (http://www.morphism.de/~markusp/).
>> >maintained by:
>> > Markus Pfeiffer (http://www.morphism.de/~markusp/) and
>> > The GAP Team (supp...@gap-system.org).
>> >Homepage: https://gap-packages.github.io/crypting/
>> >Report issues at https://github.com/gap-packages/crypting/issues
>> >────────────────────────────────────────────────────────────────────────────
>> >true
>> >
>> >That is all that I know about this.
>> >
>> >- Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/sage-devel/CAAWYfq03CzoUj1LV0Go3nwBU1VmR1Rz4zw2CKxvobw%2Byj6tc-A%40mail.gmail.com.
