x11/gnustep/libobjc2 failed to build

[Antoine Jacoutot]

>>> Building on exopi-5 under x11/gnustep/libobjc2
BDEPENDS = [devel/cmake;devel/robin-map;devel/ninja]
DIST = [x11/gnustep/libobjc2:gnustep/libobjc2-2.2.tar.gz]
FULLPKGNAME = gnustep-libobjc2-2.2p0
(Junk lock obtained for exopi-5 at 1709393315.42)
>>> Running depends in x11/gnustep/libobjc2 at 1709393315.45
   last junk was in net/miniupnp/libnatpmp
/usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
was: /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
/usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
>>> Running show-prepare-results in x11/gnustep/libobjc2 at 1709393318.75
===> x11/gnustep/libobjc2
===> Building from scratch gnustep-libobjc2-2.2p0
===> gnustep-libobjc2-2.2p0 depends on: robin-map-* -> robin-map-1.2.1
===> gnustep-libobjc2-2.2p0 depends on: cmake-* -> cmake-3.28.3v0
===> gnustep-libobjc2-2.2p0 depends on: ninja-* -> ninja-1.11.1
===>  Verifying specs:  c++ c++abi pthread m
===>  found c++.10.0 c++abi.7.0 pthread.27.1 m.10.1
cmake-3.28.3v0
ninja-1.11.1
robin-map-1.2.1
(Junk lock released for exopi-5 at 1709393320.71)
distfiles size=203442
>>> Running build in x11/gnustep/libobjc2 at 1709393320.74
===> x11/gnustep/libobjc2
===>  Checking files for gnustep-libobjc2-2.2p0
`/exopi-cvs/ports/distfiles/gnustep/libobjc2-2.2.tar.gz' is up to date.
>> (SHA256) gnustep/libobjc2-2.2.tar.gz: OK
===>  Extracting for gnustep-libobjc2-2.2p0
===>  Patching for gnustep-libobjc2-2.2p0
===>  Compiler link: clang -> /usr/bin/clang
===>  Compiler link: clang++ -> /usr/bin/clang++
===>  Compiler link: cc -> /usr/bin/cc
===>  Compiler link: c++ -> /usr/bin/c++
===>  Generating configure for gnustep-libobjc2-2.2p0
===>  Configuring for gnustep-libobjc2-2.2p0
-- The C compiler identification is Clang 16.0.6
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc
-- The CXX compiler identification is Clang 16.0.6
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc - 
skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/c++ 
- skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The OBJC compiler identification is Clang 16.0.6
-- The OBJCXX compiler identification is Clang 16.0.6
-- Detecting OBJC compiler ABI info
-- Detecting OBJC compiler ABI info - done
-- Check for working OBJC compiler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc 
- skipped
-- Detecting OBJCXX compiler ABI info
-- Detecting OBJCXX compiler ABI info - done
-- Check for working OBJCXX compiler: 
/exopi-obj/pobj/gnustep-libobjc2-2.2/bin/c++ - skipped
-- Architecture: x86_64
-- Could NOT find Git (missing: GIT_EXECUTABLE) 
-- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
CMake Error at /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 
(message):
  error: could not find git for clone of robinmap-populate
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
(_ep_add_download_command)
  CMakeLists.txt:29 (ExternalProject_Add)


-- Configuring incomplete, errors occurred!

CMake Error at /usr/local/share/cmake/Modules/FetchContent.cmake:1667 (message):
  CMake step for robinmap failed: 1
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FetchContent.cmake:1819:EVAL:2 
(__FetchContent_directPopulate)
  /usr/local/share/cmake/Modules/FetchContent.cmake:1819 (cmake_language)
  /usr/local/share/cmake/Modules/FetchContent.cmake:2033 (FetchContent_Populate)
  CMakeLists.txt:135 (FetchContent_MakeAvailable)


-- Configuring incomplete, errors occurred!
*** Error 1 in x11/gnustep/libobjc2 
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:3022 'do-configure': @cd 
/exopi-obj/pobj/gnustep-libobjc...)
*** Error 2 in x11/gnustep/libobjc2 
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:3042 
'/exopi-obj/pobj/gnustep-libobjc2-2.2/build-amd64/.configure_done')
*** Error 2 in x11/gnustep/libobjc2 
(/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2704 'build': 
@lock=gnustep-libobjc2-2.2p0;  export _LOC...)
===> Exiting x11/gnustep/libobjc2 with an error
*** Error 1 in /exopi-cvs/ports (infrastructure/mk/bsd.port.subdir.mk:144 
'build': @: ${echo_msg:=echo};  : ${target:=build};  for i in ; do...)
>>> Ended at 1709393329.27
max_stuck=2.76/depends=3.31/show-prepare-results=1.98/build=8.56
Error: job failed with 512 on exopi-5 at 1709393329

-- 
Antoine

Re: x11/gnustep/libobjc2 failed to build

[Rafael Sadowski]

On Sun Mar 03, 2024 at 08:14:41AM +0100, Antoine Jacoutot wrote:
> 
> >>> Building on exopi-5 under x11/gnustep/libobjc2
>   BDEPENDS = [devel/cmake;devel/robin-map;devel/ninja]
>   DIST = [x11/gnustep/libobjc2:gnustep/libobjc2-2.2.tar.gz]
>   FULLPKGNAME = gnustep-libobjc2-2.2p0
> (Junk lock obtained for exopi-5 at 1709393315.42)
> >>> Running depends in x11/gnustep/libobjc2 at 1709393315.45
>last junk was in net/miniupnp/libnatpmp
> /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
> was: /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 
> robin-map-1.2.1
> /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
> >>> Running show-prepare-results in x11/gnustep/libobjc2 at 1709393318.75
> ===> x11/gnustep/libobjc2
> ===> Building from scratch gnustep-libobjc2-2.2p0
> ===> gnustep-libobjc2-2.2p0 depends on: robin-map-* -> robin-map-1.2.1
> ===> gnustep-libobjc2-2.2p0 depends on: cmake-* -> cmake-3.28.3v0
> ===> gnustep-libobjc2-2.2p0 depends on: ninja-* -> ninja-1.11.1
> ===>  Verifying specs:  c++ c++abi pthread m
> ===>  found c++.10.0 c++abi.7.0 pthread.27.1 m.10.1
> cmake-3.28.3v0
> ninja-1.11.1
> robin-map-1.2.1
> (Junk lock released for exopi-5 at 1709393320.71)
> distfiles size=203442
> >>> Running build in x11/gnustep/libobjc2 at 1709393320.74
> ===> x11/gnustep/libobjc2
> ===>  Checking files for gnustep-libobjc2-2.2p0
> `/exopi-cvs/ports/distfiles/gnustep/libobjc2-2.2.tar.gz' is up to date.
> >> (SHA256) gnustep/libobjc2-2.2.tar.gz: OK
> ===>  Extracting for gnustep-libobjc2-2.2p0
> ===>  Patching for gnustep-libobjc2-2.2p0
> ===>  Compiler link: clang -> /usr/bin/clang
> ===>  Compiler link: clang++ -> /usr/bin/clang++
> ===>  Compiler link: cc -> /usr/bin/cc
> ===>  Compiler link: c++ -> /usr/bin/c++
> ===>  Generating configure for gnustep-libobjc2-2.2p0
> ===>  Configuring for gnustep-libobjc2-2.2p0
> -- The C compiler identification is Clang 16.0.6
> -- The ASM compiler identification is Clang with GNU-like command-line
> -- Found assembler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc
> -- The CXX compiler identification is Clang 16.0.6
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc 
> - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: 
> /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- The OBJC compiler identification is Clang 16.0.6
> -- The OBJCXX compiler identification is Clang 16.0.6
> -- Detecting OBJC compiler ABI info
> -- Detecting OBJC compiler ABI info - done
> -- Check for working OBJC compiler: 
> /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc - skipped
> -- Detecting OBJCXX compiler ABI info
> -- Detecting OBJCXX compiler ABI info - done
> -- Check for working OBJCXX compiler: 
> /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/c++ - skipped
> -- Architecture: x86_64
> -- Could NOT find Git (missing: GIT_EXECUTABLE) 
> -- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
> CMake Error at /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 
> (message):
>   error: could not find git for clone of robinmap-populate
> Call Stack (most recent call first):
>   /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
> (_ep_add_download_command)
>   CMakeLists.txt:29 (ExternalProject_Add)

if (NOT tsl-robin-map_FOUND)
FetchContent_Declare(
robinmap
GIT_REPOSITORY https://github.com/Tessil/robin-map/
GIT_TAGv1.2.1)

FetchContent_MakeAvailable(robinmap)
endif()

Looks like libobjc2 needs tsl-robin-map (devel/robin-map) as dependency.

> 
> 
> -- Configuring incomplete, errors occurred!
> 
> CMake Error at /usr/local/share/cmake/Modules/FetchContent.cmake:1667 
> (message):
>   CMake step for robinmap failed: 1
> Call Stack (most recent call first):
>   /usr/local/share/cmake/Modules/FetchContent.cmake:1819:EVAL:2 
> (__FetchContent_directPopulate)
>   /usr/local/share/cmake/Modules/FetchContent.cmake:1819 (cmake_language)
>   /usr/local/share/cmake/Modules/FetchContent.cmake:2033 
> (FetchContent_Populate)
>   CMakeLists.txt:135 (FetchContent_MakeAvailable)
> 
> 
> -- Configuring incomplete, errors occurred!
> *** Error 1 in x11/gnustep/libobjc2 
> (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:3022 'do-configure': @cd 
> /exopi-obj/pobj/gnustep-libobjc...)
> *** Error 2 in x11/gnustep/libobjc2 
> (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:3042 
> '/exopi-obj/pobj/gnustep-libobjc2-2.2/build-amd64/.configure_done')
> *** Error 2 in x11/gnustep/libobjc2 
> (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2704 'build': 
> @lock=gnustep-libobjc2-2.2p0;  export _LOC...)
> ===> Exiting x11/g

Re: x11/gnustep/libobjc2 failed to build

[Antoine Jacoutot]

On Sun, Mar 03, 2024 at 08:32:41AM +0100, Rafael Sadowski wrote:
> On Sun Mar 03, 2024 at 08:14:41AM +0100, Antoine Jacoutot wrote:
> > 
> > >>> Building on exopi-5 under x11/gnustep/libobjc2
> > BDEPENDS = [devel/cmake;devel/robin-map;devel/ninja]
> > DIST = [x11/gnustep/libobjc2:gnustep/libobjc2-2.2.tar.gz]
> > FULLPKGNAME = gnustep-libobjc2-2.2p0
> > (Junk lock obtained for exopi-5 at 1709393315.42)
> > >>> Running depends in x11/gnustep/libobjc2 at 1709393315.45
> >last junk was in net/miniupnp/libnatpmp
> > /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
> > was: /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 
> > robin-map-1.2.1
> > /usr/sbin/pkg_add -aI -Drepair cmake-3.28.3v0 ninja-1.11.1 robin-map-1.2.1
> > >>> Running show-prepare-results in x11/gnustep/libobjc2 at 1709393318.75
> > ===> x11/gnustep/libobjc2
> > ===> Building from scratch gnustep-libobjc2-2.2p0
> > ===> gnustep-libobjc2-2.2p0 depends on: robin-map-* -> robin-map-1.2.1
> > ===> gnustep-libobjc2-2.2p0 depends on: cmake-* -> cmake-3.28.3v0
> > ===> gnustep-libobjc2-2.2p0 depends on: ninja-* -> ninja-1.11.1
> > ===>  Verifying specs:  c++ c++abi pthread m
> > ===>  found c++.10.0 c++abi.7.0 pthread.27.1 m.10.1
> > cmake-3.28.3v0
> > ninja-1.11.1
> > robin-map-1.2.1
> > (Junk lock released for exopi-5 at 1709393320.71)
> > distfiles size=203442
> > >>> Running build in x11/gnustep/libobjc2 at 1709393320.74
> > ===> x11/gnustep/libobjc2
> > ===>  Checking files for gnustep-libobjc2-2.2p0
> > `/exopi-cvs/ports/distfiles/gnustep/libobjc2-2.2.tar.gz' is up to date.
> > >> (SHA256) gnustep/libobjc2-2.2.tar.gz: OK
> > ===>  Extracting for gnustep-libobjc2-2.2p0
> > ===>  Patching for gnustep-libobjc2-2.2p0
> > ===>  Compiler link: clang -> /usr/bin/clang
> > ===>  Compiler link: clang++ -> /usr/bin/clang++
> > ===>  Compiler link: cc -> /usr/bin/cc
> > ===>  Compiler link: c++ -> /usr/bin/c++
> > ===>  Generating configure for gnustep-libobjc2-2.2p0
> > ===>  Configuring for gnustep-libobjc2-2.2p0
> > -- The C compiler identification is Clang 16.0.6
> > -- The ASM compiler identification is Clang with GNU-like command-line
> > -- Found assembler: /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc
> > -- The CXX compiler identification is Clang 16.0.6
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Check for working C compiler: 
> > /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc - skipped
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Check for working CXX compiler: 
> > /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/c++ - skipped
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > -- The OBJC compiler identification is Clang 16.0.6
> > -- The OBJCXX compiler identification is Clang 16.0.6
> > -- Detecting OBJC compiler ABI info
> > -- Detecting OBJC compiler ABI info - done
> > -- Check for working OBJC compiler: 
> > /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/cc - skipped
> > -- Detecting OBJCXX compiler ABI info
> > -- Detecting OBJCXX compiler ABI info - done
> > -- Check for working OBJCXX compiler: 
> > /exopi-obj/pobj/gnustep-libobjc2-2.2/bin/c++ - skipped
> > -- Architecture: x86_64
> > -- Could NOT find Git (missing: GIT_EXECUTABLE) 
> > -- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
> > CMake Error at /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 
> > (message):
> >   error: could not find git for clone of robinmap-populate
> > Call Stack (most recent call first):
> >   /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
> > (_ep_add_download_command)
> >   CMakeLists.txt:29 (ExternalProject_Add)
> 
> if (NOT tsl-robin-map_FOUND)
>   FetchContent_Declare(
>   robinmap
>   GIT_REPOSITORY https://github.com/Tessil/robin-map/
>   GIT_TAGv1.2.1)
> 
>   FetchContent_MakeAvailable(robinmap)
> endif()
> 
> Looks like libobjc2 needs tsl-robin-map (devel/robin-map) as dependency.

It already depends on it.

-- 
Antoine

Re: x11/gnustep/libobjc2 failed to build

[Theo Buehler]

> -- Could NOT find Git (missing: GIT_EXECUTABLE) 
> -- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
> CMake Error at /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 
> (message):
>   error: could not find git for clone of robinmap-populate
> Call Stack (most recent call first):
>   /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
> (_ep_add_download_command)
>   CMakeLists.txt:29 (ExternalProject_Add)

Sounds like it needs a bdep on git.

I had applied this patch (which fixes other defects in this CMakeFile):
https://marc.info/?l=openbsd-ports&m=170920085418634&w=2

and now my dpb got stuck in loops 

Detected loop, merging sets ok
| 
gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
Detected loop, merging sets ok
| 
gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
Detected loop, merging sets ok
| 
gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
Detected loop, merging sets ok
| 
gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
Detected loop, merging sets ok
| gnustep-base-1.29.0p1+gnustep-libobjc2-2.2

Re: x11/gnustep/libobjc2 failed to build

[Antoine Jacoutot]

On Sun, Mar 03, 2024 at 09:00:17AM +0100, Theo Buehler wrote:
> > -- Could NOT find Git (missing: GIT_EXECUTABLE) 
> > -- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
> > CMake Error at /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 
> > (message):
> >   error: could not find git for clone of robinmap-populate
> > Call Stack (most recent call first):
> >   /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
> > (_ep_add_download_command)
> >   CMakeLists.txt:29 (ExternalProject_Add)
> 
> Sounds like it needs a bdep on git.

That won't work because the build user isn't allowed to go online:

-- Found Git: /usr/local/bin/git (found version "2.44.0") 
[1/9] Creating directories for 'robinmap-populate'
[1/9] Performing download step (git clone) for 'robinmap-populate'
Cloning into 'robinmap-src'...
fatal: unable to access 'https://github.com/Tessil/robin-map/': getsockname() 
failed with errno 61: Connection refused
Cloning into 'robinmap-src'...
fatal: unable to access 'https://github.com/Tessil/robin-map/': getsockname() 
failed with errno 61: Connection refused
Cloning into 'robinmap-src'...
fatal: unable to access 'https://github.com/Tessil/robin-map/': getsockname() 
failed with errno 61: Connection refused
-- Had to git clone more than once: 3 times.
CMake Error at 
robinmap-subbuild/robinmap-populate-prefix/tmp/robinmap-populate-gitclone.cmake:39
 (message):
  Failed to clone repository: 'https://github.com/Tessil/robin-map/'


> I had applied this patch (which fixes other defects in this CMakeFile):
> https://marc.info/?l=openbsd-ports&m=170920085418634&w=2

This part fixes the build:

+-if (NOT tls-robin-map_FOUND)
++if (NOT tsl-robin-map_FOUND)


> 
> and now my dpb got stuck in loops 
> 
> Detected loop, merging sets ok
> | 
> gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> Detected loop, merging sets ok
> | 
> gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> Detected loop, merging sets ok
> | 
> gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> Detected loop, merging sets ok
> | 
> gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> Detected loop, merging sets ok
> | gnustep-base-1.29.0p1+gnustep-libobjc2-2.2
> 

-- 
Antoine

Re: x11/gnustep/libobjc2 failed to build

[Theo Buehler]

On Sun, Mar 03, 2024 at 09:11:47AM +0100, Antoine Jacoutot wrote:
> On Sun, Mar 03, 2024 at 09:00:17AM +0100, Theo Buehler wrote:
> > > -- Could NOT find Git (missing: GIT_EXECUTABLE) 
> > > -- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
> > > CMake Error at /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 
> > > (message):
> > >   error: could not find git for clone of robinmap-populate
> > > Call Stack (most recent call first):
> > >   /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
> > > (_ep_add_download_command)
> > >   CMakeLists.txt:29 (ExternalProject_Add)
> > 
> > Sounds like it needs a bdep on git.
> 
> That won't work because the build user isn't allowed to go online:


> This part fixes the build:
> 
> +-if (NOT tls-robin-map_FOUND)
> ++if (NOT tsl-robin-map_FOUND)

Yes, that's the typo I pointed out before sebastia sent that diff.

But fixing the build apparently creates a dependency loop, so I think
this needs more work:

> 
> 
> > 
> > and now my dpb got stuck in loops 
> > 
> > Detected loop, merging sets ok
> > | 
> > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > Detected loop, merging sets ok
> > | 
> > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > Detected loop, merging sets ok
> > | 
> > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > Detected loop, merging sets ok
> > | 
> > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > Detected loop, merging sets ok
> > | gnustep-base-1.29.0p1+gnustep-libobjc2-2.2
> > 
> 
> -- 
> Antoine

Re: x11/gnustep/libobjc2 failed to build

[Antoine Jacoutot]

On Sun, Mar 03, 2024 at 09:16:50AM +0100, Theo Buehler wrote:
> On Sun, Mar 03, 2024 at 09:11:47AM +0100, Antoine Jacoutot wrote:
> > On Sun, Mar 03, 2024 at 09:00:17AM +0100, Theo Buehler wrote:
> > > > -- Could NOT find Git (missing: GIT_EXECUTABLE) 
> > > > -- Could NOT find Git (missing: GIT_EXECUTABLE) (found version "")
> > > > CMake Error at 
> > > > /usr/local/share/cmake/Modules/ExternalProject.cmake:2910 (message):
> > > >   error: could not find git for clone of robinmap-populate
> > > > Call Stack (most recent call first):
> > > >   /usr/local/share/cmake/Modules/ExternalProject.cmake:4418 
> > > > (_ep_add_download_command)
> > > >   CMakeLists.txt:29 (ExternalProject_Add)
> > > 
> > > Sounds like it needs a bdep on git.
> > 
> > That won't work because the build user isn't allowed to go online:
> 
> 
> > This part fixes the build:
> > 
> > +-if (NOT tls-robin-map_FOUND)
> > ++if (NOT tsl-robin-map_FOUND)
> 
> Yes, that's the typo I pointed out before sebastia sent that diff.
> 
> But fixing the build apparently creates a dependency loop, so I think
> this needs more work:

Probably because devel/libdispatch has:
@conflict gnustep-libobjc2-*
@pkgpath x11/gnustep/libobjc2

and x11/gnustep/libobjc2 has:
@conflict libdispatch-*
@pkgpath devel/libdispatch

That does not make much sense...

> > > and now my dpb got stuck in loops 
> > > 
> > > Detected loop, merging sets ok
> > > | 
> > > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > > Detected loop, merging sets ok
> > > | 
> > > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > > Detected loop, merging sets ok
> > > | 
> > > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > > Detected loop, merging sets ok
> > > | 
> > > gnustep-base-1.29.0p1+gnustep-libobjc2-2.2p1+sope-5.9.1->gnustep-base-1.29.0p1+libdispatch-5.5p0+sope-5.9.1
> > > Detected loop, merging sets ok
> > > | gnustep-base-1.29.0p1+gnustep-libobjc2-2.2

-- 
Antoine

Re: x11/gnustep/libobjc2 failed to build

[Stuart Henderson]

On 2024/03/03 10:38, Antoine Jacoutot wrote:
> Probably because devel/libdispatch has:
> @conflict gnustep-libobjc2-*
> @pkgpath x11/gnustep/libobjc2
> 
> and x11/gnustep/libobjc2 has:
> @conflict libdispatch-*
> @pkgpath devel/libdispatch
> 
> That does not make much sense...
> 
> > > > and now my dpb got stuck in loops 

I've removed the incorrect @pkgpath markers fixing the worst of the
issues, but there is still a problem.

We can't have two ports which are used as build dependencies of other
ports having @conflicts between themselves.

This will need to be resolved rather than just marking the conflict.

Re: x11/gnustep/libobjc2 failed to build

[Sebastian Reitenbach]

On Sunday, March 03, 2024 13:32 CET, Stuart Henderson  
wrote:

> On 2024/03/03 10:38, Antoine Jacoutot wrote:
> > Probably because devel/libdispatch has:
> > @conflict gnustep-libobjc2-*
> > @pkgpath x11/gnustep/libobjc2
> > 
> > and x11/gnustep/libobjc2 has:
> > @conflict libdispatch-*
> > @pkgpath devel/libdispatch
> > 
> > That does not make much sense...
> > 
> > > > > and now my dpb got stuck in loops 
> 
> I've removed the incorrect @pkgpath markers fixing the worst of the
> issues, but there is still a problem.
> 
> We can't have two ports which are used as build dependencies of other
> ports having @conflicts between themselves.
> 
> This will need to be resolved rather than just marking the conflict.
> 

I'm sorry for the mess I created. I intended to get it in quickly, due to the
endbr64 fixes work. As the version in tree is very old, and the just recently
released 2.2 finally builds and doesn't show runtime errors in apps linked 
against it.

The only port that depends on libobjc2, that had a dependency to libdispatch
was x11/gnustep/base, but that one I "fixed", not depending on libdispatch 
anymore.
gnustep-base-1.29.0 REVISION 1 should not depend on libdispatch anymore.

If I understand removing the @pkgpath fixed the bigger part of the issue?
That there is a conflict with libdispatch, is already known for upstream.

Sebastian

Re: x11/gnustep/libobjc2 failed to build

[Stuart Henderson]

On 2024/03/03 20:31, Sebastian Reitenbach wrote:
> On Sunday, March 03, 2024 13:32 CET, Stuart Henderson  
> wrote:
> 
> > On 2024/03/03 10:38, Antoine Jacoutot wrote:
> > > Probably because devel/libdispatch has:
> > > @conflict gnustep-libobjc2-*
> > > @pkgpath x11/gnustep/libobjc2
> > > 
> > > and x11/gnustep/libobjc2 has:
> > > @conflict libdispatch-*
> > > @pkgpath devel/libdispatch
> > > 
> > > That does not make much sense...
> > > 
> > > > > > and now my dpb got stuck in loops 
> > 
> > I've removed the incorrect @pkgpath markers fixing the worst of the
> > issues, but there is still a problem.
> > 
> > We can't have two ports which are used as build dependencies of other
> > ports having @conflicts between themselves.
> > 
> > This will need to be resolved rather than just marking the conflict.
> > 
> 
> I'm sorry for the mess I created. I intended to get it in quickly, due to the
> endbr64 fixes work. As the version in tree is very old, and the just recently
> released 2.2 finally builds and doesn't show runtime errors in apps linked 
> against it.
> 
> The only port that depends on libobjc2, that had a dependency to libdispatch
> was x11/gnustep/base, but that one I "fixed", not depending on libdispatch 
> anymore.
> gnustep-base-1.29.0 REVISION 1 should not depend on libdispatch anymore.
> 
> If I understand removing the @pkgpath fixed the bigger part of the issue?
> That there is a conflict with libdispatch, is already known for upstream.
> 
> Sebastian
> 

Other ports in the tree depend on libdispatch.

If a machine has built a port which depends on libobjc2 it can then
not build a port which depends on libdispatch, and vice-versa, until
the conflicting port has been uninstalled.

Unneeded packages *are* often removed periodically during a build,
but there's no control of when that happens, and it cannot happen if a
port with "DPB_PROPERTIES=nojunk" is built. (And, if a "nojunk" port
starts building and fails, there will be no more periodic junking
on that machine at all without manual intervention, so if either
conflicting package is installed at the time, any ports depending
on the other conflicting package will fail on that build machine).

Re: x11/gnustep/libobjc2 failed to build

[Stuart Henderson]

On 2024/03/03 20:52, Stuart Henderson wrote:
> On 2024/03/03 20:31, Sebastian Reitenbach wrote:
> > If I understand removing the @pkgpath fixed the bigger part of the issue?

PS "bigger part of the issue" = "bulk builds were breaking because the
dependency loop resulted in too much disk space being eatern" but the
remaining problem is still fairly important.

Re: x11/gnustep/libobjc2 failed to build

[Sebastian Reitenbach]

On Sunday, March 03, 2024 21:56 CET, Stuart Henderson  
wrote:

> On 2024/03/03 20:52, Stuart Henderson wrote:
> > On 2024/03/03 20:31, Sebastian Reitenbach wrote:
> > > If I understand removing the @pkgpath fixed the bigger part of the issue?
> 
> PS "bigger part of the issue" = "bulk builds were breaking because the
> dependency loop resulted in too much disk space being eatern" but the
> remaining problem is still fairly important.
> 


The conflicting file is the include/Block.h

Nothing that depends on libobjc2, really needs it. gnustep-base is configured to
not search for Blocks runtime.

This, with another bump of libdispatch, and removed @conflict in PLIST
should do the trick.

OK?
Sebastian

Index: Makefile
===
RCS file: /cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -r1.35 Makefile
--- Makefile3 Mar 2024 12:28:24 -   1.35
+++ Makefile4 Mar 2024 20:02:11 -
@@ -4,15 +4,15 @@
 
 # note: this port does not use the gnustep module
 VERSION =  2.2
-REVISION = 1
+REVISION = 2
 GH_ACCOUNT =   gnustep
 GH_PROJECT =   libobjc2
 GH_TAGNAME =   v${VERSION}
 DISTNAME = libobjc2-${VERSION:S/_//}
 PKGNAME =  gnustep-${DISTNAME}
 
-SHARED_LIBS += objc2   2.0
-SHARED_LIBS +=  objcxx 1.0
+SHARED_LIBS += objc2   3.0
+SHARED_LIBS +=  objcxx 2.0
 
 CATEGORIES =   x11/gnustep devel
 
@@ -45,5 +45,8 @@
 
 MAKE_FLAGS +=   LIBOBJCLIBNAME=objc2 \
 LIBOBJC=libobjc2
+
+post-install:
+   mv ${PREFIX}/include/Block.h ${PREFIX}/include/Block-libobjc2.h
 
 .include 
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/gnustep/libobjc2/pkg/PLIST,v
diff -u -r1.6 PLIST
--- pkg/PLIST   3 Mar 2024 12:28:24 -   1.6
+++ pkg/PLIST   4 Mar 2024 20:02:11 -
@@ -1,5 +1,4 @@
-@conflict libdispatch-*
-include/Block.h
+include/Block-libobjc2.h
 include/Block_private.h
 include/gnustep/
 include/gnustep/objc/

Re: x11/gnustep/libobjc2 failed to build

[Jeremie Courreges-Anglas]

Le Mon, Mar 04, 2024 at 10:26:02PM +0100, Sebastian Reitenbach a écrit :
> On Sunday, March 03, 2024 21:56 CET, Stuart Henderson  
> wrote:
> 
> > On 2024/03/03 20:52, Stuart Henderson wrote:
> > > On 2024/03/03 20:31, Sebastian Reitenbach wrote:
> > > > If I understand removing the @pkgpath fixed the bigger part of the 
> > > > issue?
> > 
> > PS "bigger part of the issue" = "bulk builds were breaking because the
> > dependency loop resulted in too much disk space being eatern" but the
> > remaining problem is still fairly important.
> > 
> 
> 
> The conflicting file is the include/Block.h
> 
> Nothing that depends on libobjc2, really needs it. gnustep-base is configured 
> to
> not search for Blocks runtime.

I'm testing something similar, slightly more conservative: move
Block.h and Block_private.h to /usr/local/include/gnustep/; the idea
is that directory is prepended to C(PP)FLAGS during the build of the
gnustep ports/consumers, thus ports that really need to include
Block.h can find it out of the box.  This partial build is still
ongoing:

  I=515 B=21 Q=2 T=25 F=0 !=0

and so far ''stat /usr/local/include/gnustep/Block.h'' says no port
has tried to include the file.  So you're definitely on the right
track.  The build should complete later this night.

> This, with another bump of libdispatch, and removed @conflict in PLIST
> should do the trick.
> 
> OK?

You're just moving a header, so why the shared lib major bump?
(You've already bumped the major in the last update.)

Depending on my ongoing build it could be better to move both Block*.h
headers to /usr/local/include/gnustep where they can be used, or to
just zap both of them if they're really not useful.

> Sebastian
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -r1.35 Makefile
> --- Makefile  3 Mar 2024 12:28:24 -   1.35
> +++ Makefile  4 Mar 2024 20:02:11 -
> @@ -4,15 +4,15 @@
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   1
> +REVISION =   2
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
>  DISTNAME =   libobjc2-${VERSION:S/_//}
>  PKGNAME =gnustep-${DISTNAME}
>  
> -SHARED_LIBS +=   objc2   2.0
> -SHARED_LIBS +=  objcxx   1.0
> +SHARED_LIBS +=   objc2   3.0
> +SHARED_LIBS +=  objcxx   2.0
>  
>  CATEGORIES = x11/gnustep devel
>  
> @@ -45,5 +45,8 @@
>  
>  MAKE_FLAGS +=   LIBOBJCLIBNAME=objc2 \
>  LIBOBJC=libobjc2
> +
> +post-install:
> + mv ${PREFIX}/include/Block.h ${PREFIX}/include/Block-libobjc2.h
>  
>  .include 
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/x11/gnustep/libobjc2/pkg/PLIST,v
> diff -u -r1.6 PLIST
> --- pkg/PLIST 3 Mar 2024 12:28:24 -   1.6
> +++ pkg/PLIST 4 Mar 2024 20:02:11 -
> @@ -1,5 +1,4 @@
> -@conflict libdispatch-*
> -include/Block.h
> +include/Block-libobjc2.h
>  include/Block_private.h
>  include/gnustep/
>  include/gnustep/objc/
> 

-- 
jca

Re: x11/gnustep/libobjc2 failed to build

[Jeremie Courreges-Anglas]

Le Mon, Mar 04, 2024 at 10:48:46PM +0100, Jeremie Courreges-Anglas a écrit :
> Le Mon, Mar 04, 2024 at 10:26:02PM +0100, Sebastian Reitenbach a écrit :
> > On Sunday, March 03, 2024 21:56 CET, Stuart Henderson 
> >  wrote:
> > 
> > > On 2024/03/03 20:52, Stuart Henderson wrote:
> > > > On 2024/03/03 20:31, Sebastian Reitenbach wrote:
> > > > > If I understand removing the @pkgpath fixed the bigger part of the 
> > > > > issue?
> > > 
> > > PS "bigger part of the issue" = "bulk builds were breaking because the
> > > dependency loop resulted in too much disk space being eatern" but the
> > > remaining problem is still fairly important.
> > > 
> > 
> > 
> > The conflicting file is the include/Block.h
> > 
> > Nothing that depends on libobjc2, really needs it. gnustep-base is 
> > configured to
> > not search for Blocks runtime.
> 
> I'm testing something similar, slightly more conservative: move
> Block.h and Block_private.h to /usr/local/include/gnustep/; the idea
> is that directory is prepended to C(PP)FLAGS during the build of the
> gnustep ports/consumers, thus ports that really need to include
> Block.h can find it out of the box.  This partial build is still
> ongoing:
> 
>   I=515 B=21 Q=2 T=25 F=0 !=0

No error.

> and so far ''stat /usr/local/include/gnustep/Block.h'' says no port
> has tried to include the file.

No port has tried to include that file, as you expected.

> So you're definitely on the right
> track.  The build should complete later this night.
> 
> > This, with another bump of libdispatch, and removed @conflict in PLIST
> > should do the trick.
> > 
> > OK?
> 
> You're just moving a header, so why the shared lib major bump?
> (You've already bumped the major in the last update.)
> 
> Depending on my ongoing build it could be better to move both Block*.h
> headers to /usr/local/include/gnustep where they can be used, or to
> just zap both of them if they're really not useful.

I think moving both files under /usr/local/include/gnustep makes most
sense but you get the last word.

ok jca@

> > Sebastian
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/x11/gnustep/libobjc2/Makefile,v
> > diff -u -r1.35 Makefile
> > --- Makefile3 Mar 2024 12:28:24 -   1.35
> > +++ Makefile4 Mar 2024 20:02:11 -
> > @@ -4,15 +4,15 @@
> >  
> >  # note: this port does not use the gnustep module
> >  VERSION =  2.2
> > -REVISION = 1
> > +REVISION = 2
> >  GH_ACCOUNT =   gnustep
> >  GH_PROJECT =   libobjc2
> >  GH_TAGNAME =   v${VERSION}
> >  DISTNAME = libobjc2-${VERSION:S/_//}
> >  PKGNAME =  gnustep-${DISTNAME}
> >  
> > -SHARED_LIBS += objc2   2.0
> > -SHARED_LIBS +=  objcxx 1.0
> > +SHARED_LIBS += objc2   3.0
> > +SHARED_LIBS +=  objcxx 2.0
> >  
> >  CATEGORIES =   x11/gnustep devel
> >  
> > @@ -45,5 +45,8 @@
> >  
> >  MAKE_FLAGS +=   LIBOBJCLIBNAME=objc2 \
> >  LIBOBJC=libobjc2
> > +
> > +post-install:
> > +   mv ${PREFIX}/include/Block.h ${PREFIX}/include/Block-libobjc2.h
> >  
> >  .include 
> > Index: pkg/PLIST
> > ===
> > RCS file: /cvs/ports/x11/gnustep/libobjc2/pkg/PLIST,v
> > diff -u -r1.6 PLIST
> > --- pkg/PLIST   3 Mar 2024 12:28:24 -   1.6
> > +++ pkg/PLIST   4 Mar 2024 20:02:11 -
> > @@ -1,5 +1,4 @@
> > -@conflict libdispatch-*
> > -include/Block.h
> > +include/Block-libobjc2.h
> >  include/Block_private.h
> >  include/gnustep/
> >  include/gnustep/objc/
> > 
> 
> -- 
> jca
> 

-- 
jca

Re: x11/gnustep/libobjc2 failed to build

[Sebastian Reitenbach]

On Tuesday, March 05, 2024 08:01 CET, Jeremie Courreges-Anglas 
 wrote:

> Le Mon, Mar 04, 2024 at 10:48:46PM +0100, Jeremie Courreges-Anglas a écrit :
> > Le Mon, Mar 04, 2024 at 10:26:02PM +0100, Sebastian Reitenbach a écrit :
> > > On Sunday, March 03, 2024 21:56 CET, Stuart Henderson 
> > >  wrote:
> > > 
> > > > On 2024/03/03 20:52, Stuart Henderson wrote:
> > > > > On 2024/03/03 20:31, Sebastian Reitenbach wrote:
> > > > > > If I understand removing the @pkgpath fixed the bigger part of the 
> > > > > > issue?
> > > > 
> > > > PS "bigger part of the issue" = "bulk builds were breaking because the
> > > > dependency loop resulted in too much disk space being eatern" but the
> > > > remaining problem is still fairly important.
> > > > 
> > > 
> > > 
> > > The conflicting file is the include/Block.h
> > > 
> > > Nothing that depends on libobjc2, really needs it. gnustep-base is 
> > > configured to
> > > not search for Blocks runtime.
> > 
> > I'm testing something similar, slightly more conservative: move
> > Block.h and Block_private.h to /usr/local/include/gnustep/; the idea
> > is that directory is prepended to C(PP)FLAGS during the build of the
> > gnustep ports/consumers, thus ports that really need to include
> > Block.h can find it out of the box.  This partial build is still
> > ongoing:
> > 
> >   I=515 B=21 Q=2 T=25 F=0 !=0
> 
> No error.
> 
> > and so far ''stat /usr/local/include/gnustep/Block.h'' says no port
> > has tried to include the file.
> 
> No port has tried to include that file, as you expected.
> 
> > So you're definitely on the right
> > track.  The build should complete later this night.
> > 
> > > This, with another bump of libdispatch, and removed @conflict in PLIST
> > > should do the trick.
> > > 
> > > OK?
> > 
> > You're just moving a header, so why the shared lib major bump?
> > (You've already bumped the major in the last update.)
> > 
> > Depending on my ongoing build it could be better to move both Block*.h
> > headers to /usr/local/include/gnustep where they can be used, or to
> > just zap both of them if they're really not useful.
> 
> I think moving both files under /usr/local/include/gnustep makes most
> sense but you get the last word.
> 
> ok jca@

thank you, followed your suggestion to move to /usr/local/include/gnustep.
as well as removed the conflict from devel/libdispatch

Sebastian

> 
> > > Sebastian
> > > 
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/x11/gnustep/libobjc2/Makefile,v
> > > diff -u -r1.35 Makefile
> > > --- Makefile  3 Mar 2024 12:28:24 -   1.35
> > > +++ Makefile  4 Mar 2024 20:02:11 -
> > > @@ -4,15 +4,15 @@
> > >  
> > >  # note: this port does not use the gnustep module
> > >  VERSION =2.2
> > > -REVISION =   1
> > > +REVISION =   2
> > >  GH_ACCOUNT = gnustep
> > >  GH_PROJECT = libobjc2
> > >  GH_TAGNAME = v${VERSION}
> > >  DISTNAME =   libobjc2-${VERSION:S/_//}
> > >  PKGNAME =gnustep-${DISTNAME}
> > >  
> > > -SHARED_LIBS +=   objc2   2.0
> > > -SHARED_LIBS +=  objcxx   1.0
> > > +SHARED_LIBS +=   objc2   3.0
> > > +SHARED_LIBS +=  objcxx   2.0
> > >  
> > >  CATEGORIES = x11/gnustep devel
> > >  
> > > @@ -45,5 +45,8 @@
> > >  
> > >  MAKE_FLAGS +=   LIBOBJCLIBNAME=objc2 \
> > >  LIBOBJC=libobjc2
> > > +
> > > +post-install:
> > > + mv ${PREFIX}/include/Block.h ${PREFIX}/include/Block-libobjc2.h
> > >  
> > >  .include 
> > > Index: pkg/PLIST
> > > ===
> > > RCS file: /cvs/ports/x11/gnustep/libobjc2/pkg/PLIST,v
> > > diff -u -r1.6 PLIST
> > > --- pkg/PLIST 3 Mar 2024 12:28:24 -   1.6
> > > +++ pkg/PLIST 4 Mar 2024 20:02:11 -
> > > @@ -1,5 +1,4 @@
> > > -@conflict libdispatch-*
> > > -include/Block.h
> > > +include/Block-libobjc2.h
> > >  include/Block_private.h
> > >  include/gnustep/
> > >  include/gnustep/objc/
> > > 
> > 
> > -- 
> > jca
> > 
> 
> -- 
> jca

Re: x11/gnustep/libobjc2 failed to build

[Theo Buehler]

> thank you, followed your suggestion to move to /usr/local/include/gnustep.
> as well as removed the conflict from devel/libdispatch

Could you please resend the endbr64 patches with Cc kettenis? They
should make release.

gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Jeremie Courreges-Anglas]

Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> Could you please resend the endbr64 patches with Cc kettenis? They
> should make release.

Since I now have a laptop with BTI I figured I was going to give this
a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
For the amd64 diff I'm deliberately not caring about the assembly for
Windows.  I can't test the arm64 part but it looks simple.

ok?

Sebastian, feel free to commit this if it matches your previous diff.


Index: Makefile
===
RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -p -r1.37 Makefile
--- Makefile5 Mar 2024 16:11:15 -   1.37
+++ Makefile6 Mar 2024 17:26:11 -
@@ -4,7 +4,7 @@ COMMENT =   GNUstep libobjc2 objective-c r
 
 # note: this port does not use the gnustep module
 VERSION =  2.2
-REVISION = 3
+REVISION = 4
 GH_ACCOUNT =   gnustep
 GH_PROJECT =   libobjc2
 GH_TAGNAME =   v${VERSION}
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
@@ -0,0 +1,11 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend_stret):
+   EH_START
++  btic
+ 
+   cbzx0, 4f   // Skip everything if the receiver is 
nil
+  // Jump to 6: if this is a small 
object
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
@@ -0,0 +1,15 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
 objc_msgSend.x86-64.S
+@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
+ TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend):
++  endbr64
+   MSGSEND objc_msgSend, %rdi, %rsi
+ .globl CDECL(objc_msgSend_stret)
+ TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
+ CDECL(objc_msgSend_stret):
++  endbr64
+   MSGSEND objc_msgSend_stret, %rsi, %rdx
+ #endif


-- 
jca

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Theo Buehler]

On Wed, Mar 06, 2024 at 07:02:35PM +0100, Jeremie Courreges-Anglas wrote:
> Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > Could you please resend the endbr64 patches with Cc kettenis? They
> > should make release.
> 
> Since I now have a laptop with BTI I figured I was going to give this
> a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> For the amd64 diff I'm deliberately not caring about the assembly for
> Windows.  I can't test the arm64 part but it looks simple.
> 
> ok?

I had a somewhat different approach:
https://marc.info/?l=openbsd-ports&m=170915116023144&w=2

Since you add the endbr64 before the MSGSEND macro, they now come before
.cfi_startproc. In all other patches I'm aware of, we put them after.
Not sure if that will matter in the future.

I also added landing pads to the trampolines; I'm sure the old libobjc2
warned about these with kettenis's ld.lld diff. Maybe it's no longer
needed.

> 
> Sebastian, feel free to commit this if it matches your previous diff.
> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  6 Mar 2024 17:19:04 -
> @@ -0,0 +1,11 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend_stret):
> + EH_START
> ++btic
> + 
> + cbzx0, 4f   // Skip everything if the receiver is 
> nil
> +// Jump to 6: if this is a small 
> object
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   6 Mar 2024 17:18:56 -
> @@ -0,0 +1,15 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend):
> ++endbr64
> + MSGSEND objc_msgSend, %rdi, %rsi
> + .globl CDECL(objc_msgSend_stret)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> + CDECL(objc_msgSend_stret):
> ++endbr64
> + MSGSEND objc_msgSend_stret, %rsi, %rdx
> + #endif
> 
> 
> -- 
> jca
> 

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Mark Kettenis]

> Date: Wed, 6 Mar 2024 19:02:35 +0100
> From: Jeremie Courreges-Anglas 
> 
> Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > Could you please resend the endbr64 patches with Cc kettenis? They
> > should make release.
> 
> Since I now have a laptop with BTI I figured I was going to give this
> a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> For the amd64 diff I'm deliberately not caring about the assembly for
> Windows.  I can't test the arm64 part but it looks simple.
> 
> ok?
> 
> Sebastian, feel free to commit this if it matches your previous diff.

Looks right to me.

> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  6 Mar 2024 17:19:04 -
> @@ -0,0 +1,11 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend_stret):
> + EH_START
> ++btic
> + 
> + cbzx0, 4f   // Skip everything if the receiver is 
> nil
> +// Jump to 6: if this is a small 
> object
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   6 Mar 2024 17:18:56 -
> @@ -0,0 +1,15 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> + CDECL(objc_msgSend_fpret):
> + CDECL(objc_msgSend):
> ++endbr64
> + MSGSEND objc_msgSend, %rdi, %rsi
> + .globl CDECL(objc_msgSend_stret)
> + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> + CDECL(objc_msgSend_stret):
> ++endbr64
> + MSGSEND objc_msgSend_stret, %rsi, %rdx
> + #endif
> 
> 
> -- 
> jca
> 

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Mark Kettenis]

> Date: Wed, 06 Mar 2024 23:32:51 +0100
> From: Mark Kettenis 
> 
> > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > From: Jeremie Courreges-Anglas 
> > 
> > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > should make release.
> > 
> > Since I now have a laptop with BTI I figured I was going to give this
> > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > For the amd64 diff I'm deliberately not caring about the assembly for
> > Windows.  I can't test the arm64 part but it looks simple.
> > 
> > ok?
> > 
> > Sebastian, feel free to commit this if it matches your previous diff.
> 
> Looks right to me.

Actually, the arm64 bit is probably incomplete.  And tb@ has a point
that endbr64 should be after the .cfi_startproc.

> > Index: Makefile
> > ===
> > RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> > diff -u -p -r1.37 Makefile
> > --- Makefile5 Mar 2024 16:11:15 -   1.37
> > +++ Makefile6 Mar 2024 17:26:11 -
> > @@ -4,7 +4,7 @@ COMMENT =   GNUstep libobjc2 objective-c r
> >  
> >  # note: this port does not use the gnustep module
> >  VERSION =  2.2
> > -REVISION = 3
> > +REVISION = 4
> >  GH_ACCOUNT =   gnustep
> >  GH_PROJECT =   libobjc2
> >  GH_TAGNAME =   v${VERSION}
> > Index: patches/patch-objc_msgSend_aarch64_S
> > ===
> > RCS file: patches/patch-objc_msgSend_aarch64_S
> > diff -N patches/patch-objc_msgSend_aarch64_S
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
> > @@ -0,0 +1,11 @@
> > +Index: objc_msgSend.aarch64.S
> > +--- objc_msgSend.aarch64.S.orig
> >  objc_msgSend.aarch64.S
> > +@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
> > + CDECL(objc_msgSend_fpret):
> > + CDECL(objc_msgSend_stret):
> > +   EH_START
> > ++  btic
> > + 
> > +   cbzx0, 4f   // Skip everything if the receiver is 
> > nil
> > +  // Jump to 6: if this is a small 
> > object
> > Index: patches/patch-objc_msgSend_x86-64_S
> > ===
> > RCS file: patches/patch-objc_msgSend_x86-64_S
> > diff -N patches/patch-objc_msgSend_x86-64_S
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-objc_msgSend_x86-64_S 6 Mar 2024 17:18:56 -
> > @@ -0,0 +1,15 @@
> > +Index: objc_msgSend.x86-64.S
> > +--- objc_msgSend.x86-64.S.orig
> >  objc_msgSend.x86-64.S
> > +@@ -307,9 +307,11 @@ TYPE_DIRECTIVE(CDECL(objc_msgSend), @function)
> > + TYPE_DIRECTIVE(CDECL(objc_msgSend_fpret), @function)
> > + CDECL(objc_msgSend_fpret):
> > + CDECL(objc_msgSend):
> > ++  endbr64
> > +   MSGSEND objc_msgSend, %rdi, %rsi
> > + .globl CDECL(objc_msgSend_stret)
> > + TYPE_DIRECTIVE(CDECL(objc_msgSend_stret), @function)
> > + CDECL(objc_msgSend_stret):
> > ++  endbr64
> > +   MSGSEND objc_msgSend_stret, %rsi, %rdx
> > + #endif
> > 
> > 
> > -- 
> > jca
> > 
> 

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

Hi,


On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis  
wrote:

> > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > From: Mark Kettenis 
> > 
> > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > From: Jeremie Courreges-Anglas 
> > > 
> > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > should make release.
> > > 
> > > Since I now have a laptop with BTI I figured I was going to give this
> > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > Windows.  I can't test the arm64 part but it looks simple.
> > > 
> > > ok?
> > > 
> > > Sebastian, feel free to commit this if it matches your previous diff.
> > 
> > Looks right to me.
> 
> Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> that endbr64 should be after the .cfi_startproc.
> 

I already created a lot of mess rushing getting the update in, I'm 
a bit confused with this back and fourth. Before messing up even more, 
which of these should be the correct version, the one from tb@ or jca@ ?
And that one would also be complete in aarch64?
If I got all those threats right, the tb@ version would be the correct one?
Both attached below.


How do I get a BTI enabled machine?

Sebastian

tb@ version:

Index: patches/patch-block_trampolines_S
===
RCS file: patches/patch-block_trampolines_S
diff -N patches/patch-block_trampolines_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-block_trampolines_S   28 Feb 2024 20:08:24 -
@@ -0,0 +1,19 @@
+Index: block_trampolines.S
+--- block_trampolines.S.orig
 block_trampolines.S
+@@ -22,6 +22,7 @@
+ // x86-64 trampoline
+ 

+ .macro trampoline arg0, arg1
++  endbr64
+   mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
argument
+   xchg  \arg1, \arg0   # Swap the first and second arguments
+   jmp   *-0x1008(%rip) # Call the block function
+@@ -121,6 +122,7 @@
+ // AArch64 (ARM64) trampoline
+ 

+ .macro trampoline arg0, arg1
++  bti c
+   adr x17, #-4096
+   mov \arg1, \arg0
+   ldp \arg0, x17, [x17]
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -47,7 +47,7 @@
+ #   define EH_NOP .seh_nop
+ #else
+ // Marks the real start and end of the function
+-#   define EH_START .cfi_startproc
++#   define EH_START .cfi_startproc; bti c
+ #   define EH_END .cfi_endproc
+ 
+ // The following directives are either not
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
 objc_msgSend.x86-64.S
+@@ -8,7 +8,7 @@
+ # define SECOND_ARGUMENT %rdx
+ # define THIRD_ARGUMENT %r8
+ #else
+-# define START_PROC(x) .cfi_startproc
++# define START_PROC(x) .cfi_startproc; endbr64
+ # define END_PROC(x) .cfi_endproc
+ # define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
+ # define FIRST_ARGUMENT_STR "%rdi"



@jca version:



Index: Makefile
===
RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -p -r1.37 Makefile
--- Makefile5 Mar 2024 16:11:15 -   1.37
+++ Makefile6 Mar 2024 17:26:11 -
@@ -4,7 +4,7 @@ COMMENT =   GNUstep libobjc2 objective-c r
 
 # note: this port does not use the gnustep module
 VERSION =  2.2
-REVISION = 3
+REVISION = 4
 GH_ACCOUNT =   gnustep
 GH_PROJECT =   libobjc2
 GH_TAGNAME =   v${VERSION}
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S6 Mar 2024 17:19:04 -
@@ -0,0 +1,11 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -73,6 +73,7 @@ CDECL(objc_msgSend):
+ CDECL(objc_msgSend_fpret):
+ CDECL(objc_msgSend_stret):
+   EH_START
++  btic
+ 
+   cb

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Mark Kettenis]

> From: "Sebastian Reitenbach" 
> Date: Thu, 07 Mar 2024 09:01:13 +0100
> 
> Hi,
> 
> On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
>  wrote:
> 
> > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > From: Mark Kettenis 
> > > 
> > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > From: Jeremie Courreges-Anglas 
> > > > 
> > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > should make release.
> > > > 
> > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > 
> > > > ok?
> > > > 
> > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > 
> > > Looks right to me.
> > 
> > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > that endbr64 should be after the .cfi_startproc.
> > 
> 
> I already created a lot of mess rushing getting the update in, I'm 
> a bit confused with this back and fourth. Before messing up even more, 
> which of these should be the correct version, the one from tb@ or jca@ ?
> And that one would also be complete in aarch64?
> If I got all those threats right, the tb@ version would be the correct one?
> Both attached below.
> 
> 
> How do I get a BTI enabled machine?
> 
> Sebastian
> 
> tb@ version:

This version looks best to me.  But I suspect arm64 needs more work in
this version too.

ok kettenis@

> Index: patches/patch-block_trampolines_S
> ===
> RCS file: patches/patch-block_trampolines_S
> diff -N patches/patch-block_trampolines_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-block_trampolines_S 28 Feb 2024 20:08:24 -
> @@ -0,0 +1,19 @@
> +Index: block_trampolines.S
> +--- block_trampolines.S.orig
>  block_trampolines.S
> +@@ -22,6 +22,7 @@
> + // x86-64 trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++endbr64
> + mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
> argument
> + xchg  \arg1, \arg0   # Swap the first and second arguments
> + jmp   *-0x1008(%rip) # Call the block function
> +@@ -121,6 +122,7 @@
> + // AArch64 (ARM64) trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++bti c
> + adr x17, #-4096
> + mov \arg1, \arg0
> + ldp \arg0, x17, [x17]
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -47,7 +47,7 @@
> + #   define EH_NOP .seh_nop
> + #else
> + // Marks the real start and end of the function
> +-#   define EH_START .cfi_startproc
> ++#   define EH_START .cfi_startproc; bti c
> + #   define EH_END .cfi_endproc
> + 
> + // The following directives are either not
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -8,7 +8,7 @@
> + #   define SECOND_ARGUMENT %rdx
> + #   define THIRD_ARGUMENT %r8
> + #else
> +-#   define START_PROC(x) .cfi_startproc
> ++#   define START_PROC(x) .cfi_startproc; endbr64
> + #   define END_PROC(x) .cfi_endproc
> + #   define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
> + #   define FIRST_ARGUMENT_STR "%rdi"
> 
> 
> 
> @jca version:
> 
> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -p -r1.37 Makefile
> --- Makefile  5 Mar 2024 16:11:15 -   1.37
> +++ Makefile  6 Mar 2024 17:26:11 -
> @@ -4,7 +4,7 @@ COMMENT = GNUstep libobjc2 objective-c r
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   3
> +REVISION =   4
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/p

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Jeremie Courreges-Anglas]

Le Thu, Mar 07, 2024 at 10:28:21AM +0100, Mark Kettenis a écrit :
> > From: "Sebastian Reitenbach" 
> > Date: Thu, 07 Mar 2024 09:01:13 +0100
> > 
> > Hi,
> > 
> > On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > > From: Mark Kettenis 
> > > > 
> > > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > > From: Jeremie Courreges-Anglas 
> > > > > 
> > > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > > should make release.
> > > > > 
> > > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > > 
> > > > > ok?
> > > > > 
> > > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > > 
> > > > Looks right to me.
> > > 
> > > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > > that endbr64 should be after the .cfi_startproc.
> > > 
> > 
> > I already created a lot of mess rushing getting the update in, I'm 
> > a bit confused with this back and fourth. Before messing up even more, 
> > which of these should be the correct version, the one from tb@ or jca@ ?

Well I added to the confusion.  I did not have tb's diff at hand
yesterday, I cooked a subpar diff that fixed the crash and got trigger
happy.  That's a waste of time, sorry folks.

> > And that one would also be complete in aarch64?
> > If I got all those threats right, the tb@ version would be the correct one?
> > Both attached below.
> > 
> > 
> > How do I get a BTI enabled machine?

Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
Apple M2.

> > Sebastian
> > 
> > tb@ version:
> 
> This version looks best to me.

Agreed.

> But I suspect arm64 needs more work in
> this version too.
> 
> ok kettenis@

ok jca@

-- 
jca

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Stuart Henderson]

> > > How do I get a BTI enabled machine?
> 
> Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
> Apple M2.

Look for "Control-Flow Enforcement Technology" in the Intel cpu details
page on ark.intel.com. Yes it needs to be gen11 or newer.

AMD does not have it yet.

Cheapest way is probably the N100-based mini PCs (not speed demons but
fairly acceptable and they're really cheap).

For laptops, Thinkpad T14 are fairly common amongst developers.
(T14 g2 has gen11 CPUs, all cores the same - T14 g3 has gen12, mix
of performance + efficiency cores).

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

On Thursday, March 07, 2024 10:28 CET, Mark Kettenis  
wrote:

> > From: "Sebastian Reitenbach" 
> > Date: Thu, 07 Mar 2024 09:01:13 +0100
> > 
> > Hi,
> > 
> > On Wednesday, March 06, 2024 23:42 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > Date: Wed, 06 Mar 2024 23:32:51 +0100
> > > > From: Mark Kettenis 
> > > > 
> > > > > Date: Wed, 6 Mar 2024 19:02:35 +0100
> > > > > From: Jeremie Courreges-Anglas 
> > > > > 
> > > > > Le Wed, Mar 06, 2024 at 10:17:32AM +0100, Theo Buehler a écrit :
> > > > > > Could you please resend the endbr64 patches with Cc kettenis? They
> > > > > > should make release.
> > > > > 
> > > > > Since I now have a laptop with BTI I figured I was going to give this
> > > > > a try.  -current x11/gnustep/zipper was crashing with SIGILL on amd64.
> > > > > For the amd64 diff I'm deliberately not caring about the assembly for
> > > > > Windows.  I can't test the arm64 part but it looks simple.
> > > > > 
> > > > > ok?
> > > > > 
> > > > > Sebastian, feel free to commit this if it matches your previous diff.
> > > > 
> > > > Looks right to me.
> > > 
> > > Actually, the arm64 bit is probably incomplete.  And tb@ has a point
> > > that endbr64 should be after the .cfi_startproc.
> > > 
> > 
> > I already created a lot of mess rushing getting the update in, I'm 
> > a bit confused with this back and fourth. Before messing up even more, 
> > which of these should be the correct version, the one from tb@ or jca@ ?
> > And that one would also be complete in aarch64?
> > If I got all those threats right, the tb@ version would be the correct one?
> > Both attached below.
> > 
> > 
> > How do I get a BTI enabled machine?
> > 
> > Sebastian
> > 
> > tb@ version:
> 
> This version looks best to me.  But I suspect arm64 needs more work in
> this version too.
> 
> ok kettenis@
> 
Thank you all, this version is now in, I'll see to upstream it.

Sebastian

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

On Thursday, March 07, 2024 12:36 CET, Stuart Henderson  
wrote:

> > > > How do I get a BTI enabled machine?
> > 
> > Apparently most Intel Gen11+ CPUs have IBT.  For arm64 you need an
> > Apple M2.
> 
> Look for "Control-Flow Enforcement Technology" in the Intel cpu details
> page on ark.intel.com. Yes it needs to be gen11 or newer.
> 
> AMD does not have it yet.
> 
> Cheapest way is probably the N100-based mini PCs (not speed demons but
> fairly acceptable and they're really cheap).
> 
> For laptops, Thinkpad T14 are fairly common amongst developers.
> (T14 g2 has gen11 CPUs, all cores the same - T14 g3 has gen12, mix
> of performance + efficiency cores).
> 

I don't own such modern hardware ;)
But such N100 based mini PC looks like a viable option to add to my stack.

Sebastian

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Stuart Henderson]

On 2024/03/07 10:28, Mark Kettenis wrote:
> This version looks best to me.  But I suspect arm64 needs more work in
> this version too.

I tried to give it a spin with gnustep-based software, but no
gnustep-base package is available for arm64 yet (I suspect because of
the previous bugs in the libobjc2 port).

If I try to build gnustep-base myself it fails with BTI SIGILL during
autoconf when doing a test for libffi, so it looks like we're probably
missing something in libffi (tobhe fixed some things last November).
I'm not getting useful backtraces so not sure where in libffi it's
needed. Test program from libobjc2's autoconf files attached:

$ cc -I/usr/local/include -L/usr/local/lib config.ffi.c -lffi
$ ktrace ./a.out
a
Illegal instruction (core dumped)
$ kdump | tail
  5909 a.outRET   mmap 29349658624/0x6d5604000
  5909 a.outCALL  fcntl(1,F_ISATTY)
  5909 a.outRET   fcntl 1
  5909 a.outCALL  write(1,0x6d5604000,0x2)
  5909 a.outGIO   fd 1 wrote 2 bytes
   "a
   "
  5909 a.outRET   write 2
  5909 a.outPSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x6e74fe010 
trapno=905969666
  5909 a.outNAMI  "a.out.core"

"make test" in libffi runs ok, but picking another consumber of libffi
I tried "make test" in guile3, and that has SIGILLs too.

#include 
#include 
#include 


typedef struct cls_struct_combined {
  float a;
  float b;
  float c;
  float d;
} cls_struct_combined;

void cls_struct_combined_fn(struct cls_struct_combined arg)
{
/*
  printf("GOT %g %g %g %g,  EXPECTED 4 5 1 8\n",
 arg.a, arg.b,
 arg.c, arg.d);
  fflush(stdout);
*/
  if (arg.a != 4 || arg.b != 5 || arg.c != 1 || arg.d != 8) abort();
}

static void
cls_struct_combined_gn(ffi_cif* cif, void* resp, void** args, void* userdata)
{
  struct cls_struct_combined a0;

  a0 = *(struct cls_struct_combined*)(args[0]);

  cls_struct_combined_fn(a0);
}


int main (void)
{
  ffi_cif cif;
  void *code;
  ffi_closure *pcl = ffi_closure_alloc(sizeof(ffi_closure), &code);
  ffi_type* cls_struct_fields0[5];
  ffi_type cls_struct_type0;
  ffi_type* dbl_arg_types[5];
  struct cls_struct_combined g_dbl = {4.0, 5.0, 1.0, 8.0};

  cls_struct_type0.size = 0;
  cls_struct_type0.alignment = 0;
  cls_struct_type0.type = FFI_TYPE_STRUCT;
  cls_struct_type0.elements = cls_struct_fields0;

  cls_struct_fields0[0] = &ffi_type_float;
  cls_struct_fields0[1] = &ffi_type_float;
  cls_struct_fields0[2] = &ffi_type_float;
  cls_struct_fields0[3] = &ffi_type_float;
  cls_struct_fields0[4] = NULL;

  dbl_arg_types[0] = &cls_struct_type0;
  dbl_arg_types[1] = NULL;

  if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1, &ffi_type_void, dbl_arg_types)
!= FFI_OK) abort();

  if (ffi_prep_closure_loc(pcl, &cif, cls_struct_combined_gn, NULL, code)
!= FFI_OK) abort();

  printf("a\n");
  ((void(*)(cls_struct_combined)) (code))(g_dbl);
  printf("b\n");
  exit(0);
}

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Mark Kettenis]

> Date: Thu, 7 Mar 2024 12:55:50 +
> From: Stuart Henderson 
> 
> On 2024/03/07 10:28, Mark Kettenis wrote:
> > This version looks best to me.  But I suspect arm64 needs more work in
> > this version too.
> 
> I tried to give it a spin with gnustep-based software, but no
> gnustep-base package is available for arm64 yet (I suspect because of
> the previous bugs in the libobjc2 port).
> 
> If I try to build gnustep-base myself it fails with BTI SIGILL during
> autoconf when doing a test for libffi, so it looks like we're probably
> missing something in libffi (tobhe fixed some things last November).
> I'm not getting useful backtraces so not sure where in libffi it's
> needed. Test program from libobjc2's autoconf files attached:
> 
> $ cc -I/usr/local/include -L/usr/local/lib config.ffi.c -lffi
> $ ktrace ./a.out
> a
> Illegal instruction (core dumped)
> $ kdump | tail
>   5909 a.outRET   mmap 29349658624/0x6d5604000
>   5909 a.outCALL  fcntl(1,F_ISATTY)
>   5909 a.outRET   fcntl 1
>   5909 a.outCALL  write(1,0x6d5604000,0x2)
>   5909 a.outGIO   fd 1 wrote 2 bytes
>"a
>"
>   5909 a.outRET   write 2
>   5909 a.outPSIG  SIGILL SIG_DFL code=ILL_BTCFI addr=0x6e74fe010 
> trapno=905969666
>   5909 a.outNAMI  "a.out.core"
> 
> "make test" in libffi runs ok, but picking another consumber of libffi
> I tried "make test" in guile3, and that has SIGILLs too.

I'll take a look.

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Stuart Henderson]

Something more than the libffi fix is indeed needed for gnustep on
arm64, building x11/gnustep/back trips SIGILL when running plmerge (from
gnustep-base) as part of the build.

I propose using USE_NOBTCFI-aarch64 (to link with -z nobtcfi on aarch64)
for now on this set of ports, I think that's good enough for release.
With this, oolite runs (kind-of important for an Acorn-derived system
for historical reasons ;) and I can crash into things as well as I can
on amd64.

$ doas egdb 
/usr/local/bin/plmerge plmerge.core
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-unknown-openbsd7.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/plmerge...
Reading symbols from /usr/local/bin/.debug/plmerge.dbg...
[New process 288319]
btCore was generated by `plmerge'.
Program terminated with signal SIGILL, Illegal instruction.
#0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
NSBundle.m:2057
2057- (oneway void) release
(gdb) bt
#0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
NSBundle.m:2057
#1  0x000af6786cbc in release(objc_object*) () from 
/usr/local/lib/libobjc2.so.3.0
#2  0x000af6786b7c [PAC] in emptyPool(arc_tls*, void*) () from 
/usr/local/lib/libobjc2.so.3.0
#3  0x000af6786938 [PAC] in objc_autoreleasePoolPop () from 
/usr/local/lib/libobjc2.so.3.0
#4  0x000a975aa4fc [PAC] in -[NSAutoreleasePool dealloc] (self=0xabd627908, 
_cmd=0xa978b0778 ) at NSAutoreleasePool.m:571
#5  0x000601345908 [PAC] in gnustep_base_user_main (argc=, 
argv=, env=) at plmerge.m:139
#6  0x000601344eb8 [PAC] in _start ()


Index: games/oolite/Makefile
===
RCS file: /cvs/ports/games/oolite/Makefile,v
diff -u -p -r1.28 Makefile
--- games/oolite/Makefile   26 Sep 2023 09:41:39 -  1.28
+++ games/oolite/Makefile   8 Mar 2024 15:54:40 -
@@ -1,7 +1,7 @@
 COMMENT=   space combat and trading game in the style of Elite
 
 VERSION=   1.73.4
-REVISION = 18
+REVISION = 19
 DISTNAME=  oolite-dev-source-${VERSION}
 PKGNAME=   oolite-${VERSION}
 CATEGORIES=games
Index: www/sogo/Makefile
===
RCS file: /cvs/ports/www/sogo/Makefile,v
diff -u -p -r1.111 Makefile
--- www/sogo/Makefile   14 Jan 2024 20:49:18 -  1.111
+++ www/sogo/Makefile   8 Mar 2024 15:54:40 -
@@ -3,6 +3,7 @@ COMMENT =   web based groupware server
 VERSION =  5.9.1
 DISTNAME = SOGo-${VERSION}
 PKGNAME =  sogo-${VERSION}
+REVISION = 0
 
 SHARED_LIBS += GDLContentStore 3.0
 SHARED_LIBS += NGCards 3.1
Index: www/sope/Makefile
===
RCS file: /cvs/ports/www/sope/Makefile,v
diff -u -p -r1.99 Makefile
--- www/sope/Makefile   14 Jan 2024 20:40:45 -  1.99
+++ www/sope/Makefile   8 Mar 2024 15:54:40 -
@@ -7,6 +7,9 @@ DISTNAME =  SOPE-${VERSION}
 PKGNAME-main = sope-${VERSION}
 PKGNAME-mysql =sope-mysql-${VERSION}
 PKGNAME-postgres = sope-postgres-${VERSION}
+REVISION-main =0
+REVISION-mysql =   0
+REVISION-postgres =0
 
 SO_MAJOR=  6
 SO_MINOR=  0
Index: x11/gnustep/gnustep.port.mk
===
RCS file: /cvs/ports/x11/gnustep/gnustep.port.mk,v
diff -u -p -r1.41 gnustep.port.mk
--- x11/gnustep/gnustep.port.mk 27 Sep 2023 20:37:07 -  1.41
+++ x11/gnustep/gnustep.port.mk 8 Mar 2024 15:54:40 -
@@ -1,6 +1,18 @@
 # until tested on others
 ONLY_FOR_ARCHS ?=  ${LLD_ARCHS}
 
+USE_NOBTCFI-aarch64= Yes
+# Program terminated with signal SIGILL, Illegal instruction.
+# #0  -[NSBundle release] (self=0x14704af2d8, _cmd=) at 
NSBundle.m:2057
+# #1  0x001565473cbc in release(objc_object*) () from 
/usr/local/lib/libobjc2.so.3.0
+# #2  0x001565473ac8 [PAC] in emptyPool(arc_tls*, void*) () from 
/usr/local/lib/libobjc2.so.3.0
+# #3  0x001565473938 [PAC] in objc_autoreleasePoolPop () from 
/usr/local/lib/libobjc2.so.3.0
+# #4  0x001496a7553c [PAC] in -[NSAutoreleasePool dealloc] 
(self=0x15300e4788, _cmd=0x1496d7b7b8 ) at 
NSAutoreleasePool.m:571
+# #5  0x0014e4ff4f3c [PAC] in ?? () from 
/usr/local/lib/libgnustep-gui.so.0.32
+# #6  0x0014e4ff4414 [PAC] in ?? () from 
/usr/local/lib/libgnustep-gui.so.0.32
+

Re: gnustep/libobjc2 and BTI (was: Re: x11/gnustep/libobjc2 failed to build)

[Sebastian Reitenbach]

Sure, fine with me, OK, sebastia@


Missing signature 

> On 8. Mar 2024, at 17:05, Stuart Henderson  wrote:
> 
> Something more than the libffi fix is indeed needed for gnustep on
> arm64, building x11/gnustep/back trips SIGILL when running plmerge (from
> gnustep-base) as part of the build.
> 
> I propose using USE_NOBTCFI-aarch64 (to link with -z nobtcfi on aarch64)
> for now on this set of ports, I think that's good enough for release.
> With this, oolite runs (kind-of important for an Acorn-derived system
> for historical reasons ;) and I can crash into things as well as I can
> on amd64.
> 
> $ doas egdb 
> /usr/local/bin/plmerge plmerge.core
> GNU gdb (GDB) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "aarch64-unknown-openbsd7.5".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/local/bin/plmerge...
> Reading symbols from /usr/local/bin/.debug/plmerge.dbg...
> [New process 288319]
> btCore was generated by `plmerge'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
> NSBundle.m:2057
> 2057- (oneway void) release
> (gdb) bt
> #0  -[NSBundle release] (self=0xad1ea1f58, _cmd=) at 
> NSBundle.m:2057
> #1  0x000af6786cbc in release(objc_object*) () from 
> /usr/local/lib/libobjc2.so.3.0
> #2  0x000af6786b7c [PAC] in emptyPool(arc_tls*, void*) () from 
> /usr/local/lib/libobjc2.so.3.0
> #3  0x000af6786938 [PAC] in objc_autoreleasePoolPop () from 
> /usr/local/lib/libobjc2.so.3.0
> #4  0x000a975aa4fc [PAC] in -[NSAutoreleasePool dealloc] 
> (self=0xabd627908, _cmd=0xa978b0778 ) at 
> NSAutoreleasePool.m:571
> #5  0x000601345908 [PAC] in gnustep_base_user_main (argc=, 
> argv=, env=) at plmerge.m:139
> #6  0x000601344eb8 [PAC] in _start ()
> 
> 
> Index: games/oolite/Makefile
> ===
> RCS file: /cvs/ports/games/oolite/Makefile,v
> diff -u -p -r1.28 Makefile
> --- games/oolite/Makefile26 Sep 2023 09:41:39 -1.28
> +++ games/oolite/Makefile8 Mar 2024 15:54:40 -
> @@ -1,7 +1,7 @@
> COMMENT=space combat and trading game in the style of Elite
> 
> VERSION=1.73.4
> -REVISION =18
> +REVISION =19
> DISTNAME=oolite-dev-source-${VERSION}
> PKGNAME=oolite-${VERSION}
> CATEGORIES=games
> Index: www/sogo/Makefile
> ===
> RCS file: /cvs/ports/www/sogo/Makefile,v
> diff -u -p -r1.111 Makefile
> --- www/sogo/Makefile14 Jan 2024 20:49:18 -1.111
> +++ www/sogo/Makefile8 Mar 2024 15:54:40 -
> @@ -3,6 +3,7 @@ COMMENT =web based groupware server
> VERSION =5.9.1
> DISTNAME =SOGo-${VERSION}
> PKGNAME =sogo-${VERSION}
> +REVISION =0
> 
> SHARED_LIBS +=GDLContentStore 3.0
> SHARED_LIBS +=NGCards3.1
> Index: www/sope/Makefile
> ===
> RCS file: /cvs/ports/www/sope/Makefile,v
> diff -u -p -r1.99 Makefile
> --- www/sope/Makefile14 Jan 2024 20:40:45 -1.99
> +++ www/sope/Makefile8 Mar 2024 15:54:40 -
> @@ -7,6 +7,9 @@ DISTNAME =SOPE-${VERSION}
> PKGNAME-main =sope-${VERSION}
> PKGNAME-mysql =sope-mysql-${VERSION}
> PKGNAME-postgres =sope-postgres-${VERSION}
> +REVISION-main =0
> +REVISION-mysql =0
> +REVISION-postgres =0
> 
> SO_MAJOR=6
> SO_MINOR=0
> Index: x11/gnustep/gnustep.port.mk
> ===
> RCS file: /cvs/ports/x11/gnustep/gnustep.port.mk,v
> diff -u -p -r1.41 gnustep.port.mk
> --- x11/gnustep/gnustep.port.mk27 Sep 2023 20:37:07 -1.41
> +++ x11/gnustep/gnustep.port.mk8 Mar 2024 15:54:40 -
> @@ -1,6 +1,18 @@
> # until tested on others
> ONLY_FOR_ARCHS ?=${LLD_ARCHS}
> 
> +USE_NOBTCFI-aarch64= Yes
> +# Program terminated with signal SIGILL, Illegal instruction.
> +# #0  -[NSBundle release] (self=0x14704af2d8, _cmd=) at 
> NSBundle.m:2057
> +# #1  0x001565473cbc in release(objc_object*) () from 
> /usr/local/lib/libobjc2.so.3.0
> +# #2  0x001565473ac8 [PAC] in emptyPool(arc_tls*, void*) () from 
> /usr/local/lib/libobjc2.so.3.0
> +# #3  0x001565473938 [PAC] in objc_autoreleasePoolPop () from 
> /usr/local/lib/libobjc2.so.3.0
> +# #4  0x001496a7553c [PAC