Created attachment 127074 [details] FB3 build failure output So, my attempt to build from master with the new Firebird 3 engine still fails. Enclosed is the build output.
Hi Alex, Could you please see your autogen.input (and/or autogen.lastrun) and any option you passed to "autogen.sh"? Thanks in advance.
Reproduced by Norbert Thiebaud
Created attachment 127216 [details] patch v1 please try this patch if it doesn't work, we will switch LIBREOFFICE_FIREBIRD_LIB from workdir to instdir for ICU
Autogen output : --with-ant-home=/Volumes/BUILDHD/Shared/packages/apache-ant-1.9.2 --without-junit --enable-64-bit --with-extra-buildid --enable-extra-template --enable-extra-gallery --enable-extension-integration --with-help --with-lang=fr --enable-epm --with-package-format=dmg --enable-ext-mariadb-connector --with-system-mariadb --enable-bundle-mariadb --with-myspell-dicts --with-doxygen=/Applications/Doxygen.app/Contents/Resources/doxygen --enable-dbgutil
@Lionel : unfortunately, everytime I apply a patch in my git repo, I screw it up and don't know how to back out of it. The last time I tried Tamas' build patch, I ended up having to re-clone the repo.
(In reply to Alex Thurgood from comment #5) > @Lionel : unfortunately, everytime I apply a patch in my git repo, I screw > it up and don't know how to back out of it. The last time I tried Tamas' > build patch, I ended up having to re-clone the repo. To revert the Lionel's patch for example, you can type these (from core): git checkout -- external/firebird/ExternalProject_firebird.mk git checkout -- external/firebird/firebird-macosx.patch.1
Lionel: I tried to apply your patch directly on workdir + mk file without success. Perhaps I missed something. Then I tried to apply your patch on the patch part but I fail to do it since external/firebird/firebird-macosx.patch.1 changed in the meantime. Could you upload a new version of the patch? Otherwise, if it's simpler to use instdir instead of workdir, let's go for it.
Eike: noticing your patch about upgrade to ICU 5.8, thought you might have some idea for this bugtracker? Indeed the pb here is due to ICU integration.
No idea.
(In reply to Eike Rathke from comment #9) > No idea. Ok then. All: Just for information, I launched a thread on dev forum: http://nabble.documentfoundation.org/Firebird-build-fails-on-MacOs-tdf-101789-td4199396.html
Searching about "Could not find acceptable ICU library", I noticed this blog http://paulbeachsblog.blogspot.fr/2016/03/dyldlibrarypath-and-el-capitan.html which explains the problem with DYLD_LIBRARY_PATH from Capitan version "Apparently the behaviour is that DYLD_LIBRARY_PATH is prevented from being inherited into any system binaries. E.g. a shell. But specifying it inside a shell script will allow it to be inherited to children of that shell, unless the child is a protected process in turn." Other quotation proposing radical solution: "The simplest solution to the problem is to turn off System Integrity Protection via Recovery Mode (Command-R), and then set csrutil disable in a terminal and reboot."
Created attachment 128911 [details] patch v2 (In reply to Julien Nabet from comment #7) > (...) I tried to apply your patch on the > patch part but I fail to do it since > external/firebird/firebird-macosx.patch.1 changed in the meantime. > Could you upload a new version of the patch? Here it is. Let me know if it solves the problem.
(In reply to Julien Nabet from comment #11) > Other quotation proposing radical solution: > "The simplest solution to the problem is to turn off System Integrity > Protection > via Recovery Mode (Command-R), and then set csrutil disable in a terminal > and reboot." I tried that approach way back when El Cap first came out. Didn't work for me at the time and I haven't tried since. Obviously, that was with FB2 at the time and not FB3, but the ICU problem was the reason I tried back then.
(In reply to Alex Thurgood from comment #13) > (In reply to Julien Nabet from comment #11) > > > > ... > > via Recovery Mode (Command-R), and then set csrutil disable in a terminal > > and reboot." > > I tried that approach way back when El Cap first came out. Didn't work for > me at the time and I haven't tried since. Obviously, that was with FB2 at > the time and not FB3, but the ICU problem was the reason I tried back then. Ok. I'll try the Lionel's patch tonight when I get home. Since I'll build from scratch (I mean with a "make clean"), it'll take some time.
(In reply to Lionel Elie Mamane from comment #12) > Created attachment 128911 [details] > patch v2 > > (In reply to Julien Nabet from comment #7) > > (...) I tried to apply your patch on the > > patch part but I fail to do it since > > external/firebird/firebird-macosx.patch.1 changed in the meantime. > > Could you upload a new version of the patch? > > Here it is. Let me know if it solves the problem. On MacOS 10.12.1, with master sources updated today + firebird not disabled + your patch, LO builds! Could you submit the patch on gerrit? (if you prefer/have no time/..., I can do it, no pb of course) Anyway, thank you for your help on this!
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6040dfb5ecf9945ba9c47a87a92506ad8bc88f0b tdf#101789 work around DYLD_LIBRARY_PATH limitations on newer MacOS X It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(An alternative fix has been in place ever since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=ce170cf1f264c69e91cde268ee490584c8fbcd04> "Allow external/firebird to be built with a custom SHELL under Mac OS X 10.11". However, that fix needs a self-built bash and passing it into the build with 'make SHELL=...", see the fix's commit message. But that fix also works when you need DYLD_LIBRARY_PATH set (because you build against a nonstandard libc++, say), which the fix from comment 16 doesn't cover AFAIU.)