https://bugs.documentfoundation.org/show_bug.cgi?id=138990
--- Comment #9 from Alex Thurgood <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
