Description: Testing on Apple Silicon Most recent versions of libiodbc and ODBCAdministrator (Universal binary) installed. 1) Start the Base wizard to create an ODB file that connects to a datasource via ODBC. 2) In the first window of the DB creation dialog, choose Connect to existing database, then select ODBC from the list of possible connections. 3) On the next page, click on the button next to the DSN datasource name to be used to be able to choose from the list of declared DSN. 4) Error message : The program library libiodbc.dylib could not be loaded or is defective. Selection of the ODBC datasource is unavailable. Steps to Reproduce: See above Actual Results: Impossible to select ODBC datasource from registered DSN list Expected Results: Should be able to select a registered DNS and proceed to create an ODB file that connects to said DSN over ODBC Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Also : Collabora Office Version : 6.4-17 Build ID : 6f0073b528f4b70b1f0c34714a289ca5cf9f61fc Threads CPU : 8; OS : Mac OS X 10.16; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
Give that I'm already a member of LO-QA, I think we can remove the QA:needscomment tag.
Problem still present with Version: 7.1.2.2 / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Alex: searching about your error message, I saw this: https://blog.devart.com/iodbc-driver-manager-for-apple-silicon-m1.html "...ODBC drivers for Mac require the iODBC driver manager, but it appears that the current version only supports the x64-86 Intel architecture. After seeing numerous complaints about using ODBC drivers from users of the new Macs, we decided to build iODBC for the x64-86 and arm64 architectures from the source code of v.3.52.14 and share it with the ODBC community...". Does it correspond to what you installed?
(In reply to Julien Nabet from comment #3) > Does it correspond to what you installed? Surely that would only be true if the LO app bundle was built specifically for M1? The actual release of LO is x86_64 so should work with x86_64 components under Rosetta ?
(In reply to Alex Thurgood from comment #4) > (In reply to Julien Nabet from comment #3) > > > > Does it correspond to what you installed? > > Surely that would only be true if the LO app bundle was built specifically > for M1? > > > The actual release of LO is x86_64 so should work with x86_64 components > under Rosetta ? I'm adding Stephan in cc just to be sure but I suppose you must be right.
I've been exchanging with ActualTechnologies (ODBC driver for macOS) on this. Their take on this is that it is a bug with BigSur: "After an in-depth investigation, we have discovered that Big Sur has a bug that causes LibreOffice to fail to load the ODBC libraries. The work around is to remove the "code signing" from the LibreOffice application, which will allow it to load the libraries on Big Sur. "Code signing" is an important part of an application when it is first installed, which ensures that the application was downloaded from a reputable source. However, once the LibreOffice application has been successfully installed, the "code signing" can be safely removed since it doesn't serve a purpose at that point. We have created a simple utility that will remove the code signing from your installed LibreOffice application, which will allow you to use ODBC. Please download and launch the "LibreOffice Unsigner" available from our website: http://www.actualtech.com/downloads/libreoffice_unsigner.dmg Once you have completed the installation, restart LibreOffice. You should then be able to use ODBC data sources. Please let me know if you have any questions or encounter any issues."
(In reply to Julien Nabet from comment #5) > (In reply to Alex Thurgood from comment #4) > > (In reply to Julien Nabet from comment #3) > > > > > > > Does it correspond to what you installed? > > > > Surely that would only be true if the LO app bundle was built specifically > > for M1? > > > > > > The actual release of LO is x86_64 so should work with x86_64 components > > under Rosetta ? > > I'm adding Stephan in cc just to be sure but I suppose you must be right. Yes, apparently in a process all binary code must be either x86-64 (executed via Rosetta) or Aarch64 (executed natively).
I'm actually wondering whether the "bug" referred to by ActualTechnologies isn't actually due to Apple's shift to stub libraries in the library cache : https://developer.apple.com/forums/thread/655588
Further exchange with ActualTechnologies support : LibreOffice has chosen to use the dlopen() call to load the libiodbc.dylib (without specifying a path to the library). You are correct that Apple used to include libiodbc.dylib in the /usr/lib directory, but no longer does so. One limitation of the dlopen() function is that its behavior depends on whether the application (LibreOffice) is signed or not. From the dlopen() man page: > Note: If the main executable is a set[ug]id binary or codesigned with > entitlements, then all environment variables are ignored, and only a full > path can be used. When the app is unsigned, dlopen() will by default look in both /usr/lib and /usr/local/lib for the library. If the app is signed, it will only look in /usr/lib - the only place that securely contains libraries provided by Apple. The long term solution would be for LibreOffice to modify the call to dlopen() so that it specifies a full path to /usr/local/lib/libiodbc.dylib, and gracefully handles the condition when that library is not present. ODBC providers like ActualTech can then install libiodbc.dylib in the /usr/local/lib directory without any problems (we can't install anything in /usr/lib because of the "System Integrity Protection" (SIP) process). Our workaround for now for customers who need ODBC in LibreOffice is to install libiodbc.dylib (and its companion libiodbcinst.dylib) in /usr/local/lib, and remove the code signing from LibreOffice. We only offer this when customers request a solution. If you are not comfortable with the workaround, then you should definitely not do it. I personally believe the risk is low (much less risky than disabling SIP, for example), but I don't blame anyone for being cautious in today's world.
Bug still present on Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 8; OS: Mac OS X 12.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Bug also present in Version: 7.3.0.1 / LibreOffice Community Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d CPU threads: 8; OS: Mac OS X 12.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded LibreOffice for Apple Arm M1 aarch_64
This is a challenging and competitive game. Fall Guys is a multiplayer racing game that can have up to 60 players per match. You must overcome several hurdles to reach the finish line and be the last lucky survivor. https://fallguys.onl
Also present in version from macOS appstore: Version: 7.3.6.2 / LibreOffice Community Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e CPU threads: 8; OS: Mac OS X 12.6; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Christian: thought you might be interested in this one since it concerns macOS signing part (see https://bugs.documentfoundation.org/show_bug.cgi?id=138990#c6).
Now working for TDF Version: 7.4.1.2 / LibreOffice Community (aarch64) (web page download) Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded and using latest aarch64 mysql-odbc drivers at least for system DSNs. Still not working for LibreOffice from the AppStore, with following error message: [iODBC][Driver Manager]dlopen(/usr/local/mysql-connector-odbc-8.0.31-macos12-arm64/lib/libmyodbc8w.so, 0x0006): tried: '/usr/local/mysql-connector-odbc-8.0.31-macos12-arm64/lib/libmyodbc8w.so' (file system sandbox blocked open()), '/System/Volumes/Preboot Amended title to reflect this change.
I should add that the DSN list can at least now be retrieved for : Version: 7.4.3.2 / LibreOffice Community aarch64 Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded even if the ODBC connection fails due to sandboxing of the driver. Some improvement at least, but still not functional. I shall close this one as WFM, because bug 133056 deals with the sandboxing.