Dimitry Andric

Oh yes, it works with Rosetta just fine. You obviously have to install a x86_64 JRE, I used AdoptOpenJDK-11.0.11+9. It can then even load the libjnotify.dylib, and everything works OK, as far as I can see. Note that I simply wanted to try if I could get it work 'natively' on aarch64, as this is a common occurrence when you have a M1 Mac. :) Also, while DocFetcher showed its "Oops, this program just died" message, it then happily continued, and could index files successfully. I think it will just...

Hmm, actually the UI started up, but then shows "Oops! This program just died!" with a stack trace indicating yet another architecture mismatch related problem: program.name=DocFetcher program.version=1.1.25 program.build=20210525-2203 program.portable=false java.runtime.name=OpenJDK Runtime Environment java.runtime.version=11.0.12+7-LTS java.version=11.0.12 sun.arch.data.model=64 os.arch=aarch64 os.name=Mac OS X os.version=11.5.2 user.language=en java.lang.UnsatisfiedLinkError: /Applications/DocFetcher.app/Contents/Resources/lib/libjnotify.dylib:...

FWIW, I used swt-4.20-cocoa-macosx-aarch64.jar as the filename, and put it in /Applications/DocFetcher.app/Contents/Resources/lib/swt, but the DocFetcher shell script shows: + java -XstartOnFirstThread -Xdock:name=DocFetcher -enableassertions -Xmx1g -Xss2m -cp .::../Resources/lib/J7zip_4.43_alpha2.jar:../Resources/lib/JXGrabKey-0.3.2.jar:../Resources/lib/ansj_lucene6_plug-5.1.2.0.jar:../Resources/lib/ansj_seg-5.1.2.jar:../Resources/lib/ant-1.10.3.jar:../Resources/lib/bcmail-jdk15on-160.jar:../Resources/lib/bcpkix-jdk15on-160.jar:../Resources/lib/bcprov-jdk15on-160.jar:../Resources/lib/commons-codec-1.10.jar:../Resources/lib/commons-collections4-4.1.jar:../Resources/lib/commons-compress-1.4.1.jar:../Resources/lib/commons-io-2.4.jar:../Resources/lib/commons-logging-1.2.jar:../Resources/lib/curvesapi-1.04.jar:../Resources/lib/fontbox-2.0.13.jar:../Resources/lib/guava-12.0.jar:../Resources/lib/java-libpst-0.8.1.jar:../Resources/lib/java-unrar-0.3.jar:../Resources/lib/javolution-5.5.1.jar:../Resources/lib/jericho-html-3.4.jar:../Resources/lib/jexcelapi-2.6.12.jar:../Resources/lib/jintellitype-1.3.7.jar:../Resources/lib/jna-3.2.7.jar:../Resources/lib/jna-platform-3.2.7.jar:../Resources/lib/juniversalchardet-1.0.3.jar:../Resources/lib/log4j-1.2.17.jar:../Resources/lib/lucene-analyzers-common-6.6.3.jar:../Resources/lib/lucene-backward-codecs-6.6.3.jar:../Resources/lib/lucene-core-6.6.3.jar:../Resources/lib/lucene-highlighter-6.6.3.jar:../Resources/lib/lucene-join-6.6.3.jar:../Resources/lib/lucene-memory-6.6.3.jar:../Resources/lib/lucene-queries-6.6.3.jar:../Resources/lib/lucene-queryparser-6.6.3.jar:../Resources/lib/metadata-extractor-2.11.0.jar:../Resources/lib/mime-util-2.1.3.jar:../Resources/lib/net.sourceforge.docfetcher_1.1.25_20210525-2203.jar:../Resources/lib/nlp-lang-1.7.7.jar:../Resources/lib/pdfbox-2.0.13.jar:../Resources/lib/poi-3.17.jar:../Resources/lib/poi-ooxml-3.17.jar:../Resources/lib/poi-ooxml-schemas-3.17.jar:../Resources/lib/poi-scratchpad-3.17.jar:../Resources/lib/py4j0.10.7-py3.jar:../Resources/lib/slf4j-api-1.6.1.jar:../Resources/lib/slf4j-nop-1.6.1.jar:../Resources/lib/truezip-driver-file-7.7.7.jar:../Resources/lib/truezip-driver-tar-7.7.7.jar:../Resources/lib/truezip-driver-zip-7.7.7.jar:../Resources/lib/truezip-file-7.7.7.jar:../Resources/lib/truezip-kernel-7.7.7.jar:../Resources/lib/truezip-swing-7.7.7.jar:../Resources/lib/xmlbeans-2.6.0.jar:../Resources/lib/xmpbox-2.0.13.jar:../Resources/lib/xmpcore-5.1.3.jar:../Resources/lib/xz-1.3.jar...

Hi Joseph, any progress on this? I'd like to fix up FreeBSD's version of elftoolchain but rather not deviate from upstream. :)

Okay, let's try this other approach then. This version now retries with ${TMPDIR:-/tmp} if it gets EACCES when mkstemp() fails in the source dir. I also had to patch up copy_from_tempfile() to make it correctly work, otherwise you would still get EACCES on either the rename() or the unlink(). (All this in case the temp dir is on the same file system; if they are on different ones this does not apply.) A good test case is: mkdir foo cp abritrary.o foo chmod -w foo elfcopy foo/arbitrary.o

That might seem reasonable, but if you can't write into the destination directory, moving/copying the temporary file to the destination will also fail, but later, and all work to write the temporary file will have been for nothing. Maybe it is better to fail early?

Create tempfiles in source dir for in-place elfcopy operations

Fix linking of various components with -fno-common