Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2822: support full paths to libraries in LIBS variables
by Roland Haas 04 Sep '24

04 Sep '24

#2822: support full paths to libraries in LIBS variables Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): A possible workaround in `bash_utils.sh` is ```shell # NOTE: This breaks if pkg-config returns quotes strings, i.e., path names # with strings in them. It doesn't seems to happen in practice. # If it does: let us know what pkg-config prints in that case, and we # can try to fix it. local INC_DIRS=$($PKGCONFIG --cflags-only-I "$STATIC" "$LIBNAME" | perl -pe 's/(^| )+-I/\1/g') local LIB_DIRS=$($PKGCONFIG --libs-only-L "$STATIC" "$LIBNAME" | perl -pe 's/(^| )+-L/\1/g') local LIBS="" local ALLLIBS=$($PKGCONFIG --libs-only-l "$STATIC" "$LIBNAME" | perl -pe 's/(^| )+-l/\1/g') for lib in $ALLLIBS; do if [ "${lib%/*}" != "$lib" ] ; then LIB_DIRS="$LIB_DIRS ${lib%/*}" lib=${lib##*/lib} lib=${lib%.*} fi LIBS="$LIBS $lib" done ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2822/support-full-path…

1 0

#2822: support full paths to libraries in LIBS variables
by Roland Haas 04 Sep '24

04 Sep '24

#2822: support full paths to libraries in LIBS variables Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: On macOS using Homebrew `pkg-config` for HDF5 returns full library paths instead of `-lLIBNAME` stanzas: ``` rhaas@gdd6l52n-ofc Cactus % pkg-config --libs-only-l --static hdf5 -lhdf5 -lm -ldl -l/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libz.tbd -l/opt/homebrew/lib/libsz.dylib ``` This happens only for static linking. This causes g\+\+ to fail at link time: ``` rhaas@gdd6l52n-ofc Cactus % g++ `pkg-config --libs-only-L hdf5` `pkg-config --libs-only-l --static hdf5` dummy.c clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated] ld: library '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libz.tbd' not found ``` This seems like bug in the pkg-config file $\`/opt/homebrew/Cellar/hdf5/1.14.3\_1/lib/pkgconfig/hdf5.pc\`$ supplied by HomeBrew: ``` rhaas@gdd6l52n-ofc Cactus % cat /opt/homebrew/Cellar/hdf5/1.14.3_1/lib/pkgconfig/hdf5.pc prefix=/opt/homebrew/Cellar/hdf5/1.14.3_1 exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: hdf5 Description: HDF5 (Hierarchical Data Format 5) Software Library Version: 1.14.3 Cflags: -I${includedir} Libs: -L${libdir} -lhdf5 Requires: Libs.private: -lhdf5 -lm -ldl -l/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libz.tbd -l/opt/homebrew/lib/libsz.dylib -l/opt/homebrew/lib/libsz.dylib Requires.private: ``` Correct would be to not use `-l` with the full path $at least it will link$: ``` g++ `pkg-config --libs-only-L hdf5` dummy.c /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libz.tbd ``` Right now we have no way of handling full paths in LIBS files though git hash [cb3a8731](https://bitbucket.org/cactuscode/cactus/commits/cb3a873135a303223… "Cactus: New pseudo-flag `-file=`" of [cactus](https://bitbucket.org/cactuscode/cactus) proposes some $partial$ solution. This would require changes in all ExternalLibraries though $that may need to pass `LIBS` to their own `configure`$. Another solution might be $in `bash_utils.sh`$ to detect full paths in `-l` entries and split into a `-L` and a `-l` entry. This assumes knowledge of the library prefix $usually `lib`$ and extension $`.a`, `.so`, `.dylib`, `.dll`$. A workaround for HDF5 is to self-compile HDF5 using `HDF5_DIR=BUILD`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2822/support-full-path…

1 0

#2821: update PETSc to 3.21.5
by Roland Haas 03 Sep '24

03 Sep '24

#2821: update PETSc to 3.21.5 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2821/update-petsc-to-3…

1 0

#2821: update PETSc to 3.21.5
by Roland Haas 03 Sep '24

03 Sep '24

#2821: update PETSc to 3.21.5 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2821/update-petsc-to-3…

1 0

#2821: update PETSc to 3.21.5
by Roland Haas 03 Sep '24

03 Sep '24

#2821: update PETSc to 3.21.5 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: [https://github.com/EinsteinToolkit/ExternalLibraries-PETSc/pull/3](https://… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2821/update-petsc-to-3…

1 0

#2821: update PETSc to 3.21.5
by Roland Haas 03 Sep '24

03 Sep '24

#2821: update PETSc to 3.21.5 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn ExernalLibraries/PETSc fails to compile for me with gcc-14 and required both an update $to 3.12.5$ and change in how it is compiled to make its own `configure.py` pass. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2821/update-petsc-to-3…

1 0

#2819: SetMask_SphericalSurface uses LoopControl's LC_LOOP but does not require LoopControl
by Roland Haas 03 Sep '24

03 Sep '24

#2819: SetMask_SphericalSurface uses LoopControl's LC_LOOP but does not require LoopControl Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2819/setmask_spherical…

1 0

#2819: SetMask_SphericalSurface uses LoopControl's LC_LOOP but does not require LoopControl
by Roland Haas 03 Sep '24

03 Sep '24

#2819: SetMask_SphericalSurface uses LoopControl's LC_LOOP but does not require LoopControl Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/einsteintoolkit/einsteinutils/pull-requests/4](https:… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2819/setmask_spherical…

1 0

#2820: NewRadX boundary condition conflicts with symmetry condition
by Roland Haas 30 Aug '24

30 Aug '24

#2820: NewRadX boundary condition conflicts with symmetry condition Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2820/newradx-boundary-…

1 0

#2820: NewRadX boundary condition conflicts with symmetry condition
by Roland Haas 30 Aug '24

30 Aug '24

#2820: NewRadX boundary condition conflicts with symmetry condition Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn NewRadX’s radiative boundary condition conflicts with reflection $and periodic and others$ boundary condition since both end up being applied at the same time producing unexpected results. Patches to Loop and NewRadX are: [https://github.com/EinsteinToolkit/CarpetX/pull/300](https://github.com/Ein… and [https://github.com/EinsteinToolkit/SpacetimeX/pull/39](https://github.com/E… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2820/newradx-boundary-…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac