This morning, we started seeing two classes of error:
When running Rails:
rails aborted!
LoadError: dlopen(/Users/joey.schoblaska/.gem/ruby/3.1.2/gems/gda-1.1.3/lib/gda.bundle, 0x0009): Library not loaded: /opt/homebrew/opt/libgda/lib/libgda-5.0.4.dylib
Referenced from: <80449F78-4796-36DB-A108-FAFE77DD6317> /Users/joey.schoblaska/.gem/ruby/3.1.2/gems/gda-1.1.3/lib/gda.bundle
Reason: tried: '/opt/homebrew/opt/libgda/lib/libgda-5.0.4.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libgda/lib/libgda-5.0.4.dylib' (no such file), '/opt/homebrew/opt/libgda/lib/libgda-5.0.4.dylib' (no such file), '/usr/local/lib/libgda-5.0.4.dylib' (no such file), '/usr/lib/libgda-5.0.4.dylib' (no such file, not in dyld cache), '/opt/homebrew/Cellar/libgda/6.0.0/lib/libgda-5.0.4.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/libgda/6.0.0/lib/libgda-5.0.4.dylib' (no such file), '/opt/homebrew/Cellar/libgda/6.0.0/lib/libgda-5.0.4.dylib' (no such file), '/usr/local/lib/libgda-5.0.4.dylib' (no such file), '/usr/lib/libgda-5.0.4.dylib' (no such file, not in dyld cache) - /Users/joey.schoblaska/.gem/ruby/3.1.2/gems/gda-1.1.3/lib/gda.bundle
When bundle installing:
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
current directory: /Users/joey.schoblaska/.gem/ruby/3.1.2/gems/gda-1.1.3/ext/gda
/Users/joey.schoblaska/.rubies/ruby-3.1.2/bin/ruby -I /Users/joey.schoblaska/.rubies/ruby-3.1.2/lib/ruby/site_ruby/3.1.0 extconf.rb
checking for libgda/sql-parser/gda-sql-parser.h... no
libgda is missing. Try 'brew install libgda' if you are on OSX and have homebrew installed.
You can also check https://github.com/GNOME/libgda for more info on how to install
the dependency.
*** extconf.rb failed ***
https://github.com/tenderlove/gda/pull/11 is one approach, but I don't know what other changes are implied by this upgrade. It also doesn't account for supporting 5.0 if it's around 🤔
Workaround
As a workaround, I copied the previous libgda.rb formula to a local tap versioned as libgda@5, and updated bundle to use that. It seems to work enough to get around the errors.
libgda@5.rb
```ruby
class LibgdaAT5 < Formula
desc "Provides unified data access to the GNOME project"
homepage "https://www.gnome-db.org/"
url "https://download.gnome.org/sources/libgda/5.2/libgda-5.2.10.tar.xz"
sha256 "6f6cdf7b8053f553b907e0c88a6064eb48cf2751852eb24323dcf027792334c8"
license "GPL-2.0-or-later"
depends_on "gobject-introspection" => :build
depends_on "intltool" => :build
depends_on "itstool" => :build
depends_on "pkg-config" => :build
depends_on "gettext"
depends_on "glib"
depends_on "libgcrypt"
depends_on "libgee"
depends_on "openssl@1.1"
depends_on "readline"
uses_from_macos "perl" => :build
# Fix -flat_namespace being used on Big Sur and later.
patch do
url "https://raw.githubusercontent.com/Homebrew/formula-patches/03cf8088210822aa2c1ab544ed58ea04c897d9c4/libtool/configure-big_sur.diff"
sha256 "35acd6aebc19843f1a2b3a63e880baceb0f5278ab1ace661e57a502d9d78c93c"
end
def install
ENV.prepend_path "PERL5LIB", Formula["intltool"].libexec/"lib/perl5" unless OS.mac?
# this build uses the sqlite source code that comes with libgda,
# as opposed to using the system or brewed sqlite3, which is not supported on macOS,
# as mentioned in https://github.com/GNOME/libgda/blob/95eeca4b0470f347c645a27f714c62aa6e59f820/libgda/sqlite/README#L31
system "./configure", "--disable-debug",
"--disable-dependency-tracking",
"--disable-silent-rules",
"--prefix=#{prefix}",
"--disable-binreloc",
"--disable-gtk-doc",
"--without-java",
"--enable-introspection",
"--enable-system-sqlite=no"
system "make"
system "make", "install"
end
test do
system "#{bin}/gda-sql", "-v"
end
end
```
This morning, we started seeing two classes of error:
When running Rails:
When bundle installing:
At first, we thought it was the same as https://github.com/tenderlove/gda/issues/9 but installing pkg-config didn't fix it.
@gmacdougall spotted that Homebrew updated it from 5.2 to 6.0 very recently: https://github.com/Homebrew/homebrew-core/commit/0a684fbd08e6878452ef3f7f06c3d517594822b3 , and it looks like the pkg-config is named differently.
https://github.com/tenderlove/gda/pull/11 is one approach, but I don't know what other changes are implied by this upgrade. It also doesn't account for supporting 5.0 if it's around 🤔
Workaround
As a workaround, I copied the previous libgda.rb formula to a local tap versioned as
libgda@5
, and updated bundle to use that. It seems to work enough to get around the errors.libgda@5.rb
```ruby class LibgdaAT5 < Formula desc "Provides unified data access to the GNOME project" homepage "https://www.gnome-db.org/" url "https://download.gnome.org/sources/libgda/5.2/libgda-5.2.10.tar.xz" sha256 "6f6cdf7b8053f553b907e0c88a6064eb48cf2751852eb24323dcf027792334c8" license "GPL-2.0-or-later" depends_on "gobject-introspection" => :build depends_on "intltool" => :build depends_on "itstool" => :build depends_on "pkg-config" => :build depends_on "gettext" depends_on "glib" depends_on "libgcrypt" depends_on "libgee" depends_on "openssl@1.1" depends_on "readline" uses_from_macos "perl" => :build # Fix -flat_namespace being used on Big Sur and later. patch do url "https://raw.githubusercontent.com/Homebrew/formula-patches/03cf8088210822aa2c1ab544ed58ea04c897d9c4/libtool/configure-big_sur.diff" sha256 "35acd6aebc19843f1a2b3a63e880baceb0f5278ab1ace661e57a502d9d78c93c" end def install ENV.prepend_path "PERL5LIB", Formula["intltool"].libexec/"lib/perl5" unless OS.mac? # this build uses the sqlite source code that comes with libgda, # as opposed to using the system or brewed sqlite3, which is not supported on macOS, # as mentioned in https://github.com/GNOME/libgda/blob/95eeca4b0470f347c645a27f714c62aa6e59f820/libgda/sqlite/README#L31 system "./configure", "--disable-debug", "--disable-dependency-tracking", "--disable-silent-rules", "--prefix=#{prefix}", "--disable-binreloc", "--disable-gtk-doc", "--without-java", "--enable-introspection", "--enable-system-sqlite=no" system "make" system "make", "install" end test do system "#{bin}/gda-sql", "-v" end end ```With that in a tap, this workaround can be used: