Bug 38757 - Mac OS X: OOoSpotlightImporter is not 64-bit capable
Summary: Mac OS X: OOoSpotlightImporter is not 64-bit capable
Status: RESOLVED DUPLICATE of bug 58663
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: contrib (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86-64 (AMD64) macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: macOS-UI-polish
  Show dependency treegraph
 
Reported: 2011-06-28 12:37 UTC by Pete K.
Modified: 2013-08-06 07:27 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
build_error.log from attempt to build LibreOffice core under Mac OS 10.6.8. (270.91 KB, text/plain)
2012-11-08 22:32 UTC, Tom Wyant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pete K. 2011-06-28 12:37:57 UTC
LibreOffice for Mac OS X ships with a metadata importer for Spotlight, the Mac OS search system.  However, the plugin (/Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter) does not run correctly on a 64-bit system (i.e. Mac OS X "Snow Leopard"). 

Trying to run "mdimport" on an ODF document generates this error:

===============
pkidwell:Desktop > mdimport my_file.ods 
Plugin '/Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter' does not match current 64 bit architecture to import type 'org.oasis-open.opendocument.spreadsheet'.
'/Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter' should be updated.  'arch -i386 mdimport' may work as a work-around.
===============

The "arch -i386" workaround does make it work manually (i.e. I can import metadata from the Terminal command line), but it won't work for the automatic background import that Mac OS runs periodically. Thus, LibreOffice documents do not show up in Spotlight search results unless this is done manually.
Comment 1 Björn Michaelsen 2011-12-23 12:23:23 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 2 Florian Reisinger 2012-08-14 13:59:10 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 3 Florian Reisinger 2012-08-14 14:00:22 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 4 Florian Reisinger 2012-08-14 14:05:04 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 5 Florian Reisinger 2012-08-14 14:07:07 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 Tom Wyant 2012-11-08 22:32:39 UTC
Created attachment 69779 [details]
build_error.log from attempt to build LibreOffice core under Mac OS 10.6.8.

There are other (possibly fatal) errors besides the ones called out in the ticket.
Comment 7 Tom Wyant 2012-11-08 22:37:18 UTC
This still exists in LibreOffice Version 3.6.3.2 (Build ID: 58f22d5) under Mac OS 10.6.8 (Snow Leopard). An attempt to force the update gives

$ mdimport Fezziwig.ods
Plugin '/Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter' does not match current 64 bit architecture to import type 'org.oasis-open.opendocument.spreadsheet'.
'/Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter' should be updated.  'arch -i386 mdimport' may work as a work-around.

The suggested work-around produces

$ arch -i386 mdimport Fezziwig.ods
2012-11-08 17:21:38.603 mdimport[29228:a07] Cannot find function pointer MetadataImporterPluginFactory for factory A3FCC88D-B9A6-4364-8B93-92123C8A2D18 in CFBundle/CFPlugIn 0x143ed0 </Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter> (bundle, loaded)
2012-11-08 17:21:38.607 mdimport[29228:a07] Cannot find function pointer MetadataImporterPluginFactory for factory A3FCC88D-B9A6-4364-8B93-92123C8A2D18 in CFBundle/CFPlugIn 0x143ed0 </Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter> (bundle, loaded)

which I assume to mean that the importer is not a "fat binary" with both 32- and 64-bit executables.

I tried to rebuild from source, but the build failed, with the following near the end of build_error.log:

ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported fi
le format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libz.dylib, file was built for unsupported file f
ormat which is not the architecture being linked (i386)
ld: in /opt/local/lib/libz.1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Given the information
$ file /opt/local/lib/libiconv.dylib
/opt/local/lib/libiconv.dylib: Mach-O 64-bit dynamically linked shared library x86_64

I suspect that the build, had it succeeded, would have produced another 32-bit Spotlight importer.

The previous attachment goes with this set of notes.
Comment 8 Alex Thurgood 2012-11-19 09:32:50 UTC
Nothing will change here until LO can be built as a fully functional 64bit app on OSX.


Alex
Comment 9 Tom Wyant 2012-11-27 19:59:04 UTC
Well, I hoped there would be a way to build just the Spotlight plug-in, but I could not figure out how to do that. It's frustrating when a quick-n-dirty text search of an OASIS document is dead simple.

But I have an update, though I do not yet understand what it means.

I did a safe boot for other reasons (hold the shift key down when booting). Now, when I create a word processing or spreadsheet document (the only ones I have tried so far) they seem to get indexed by Spotlight. The test was to pick a search term which Spotlight could not find, crate a document with that search term, and verify that Spotlight finds it only in the document I just created.

The screwy thing comes when I try to re-index with the mdimport command. The word processing document re-indexes successfully (using /System/Library/Spotlight/RichText.mdimporter, according to mdimport -d 1), but an attempt to re-index the spreadsheet fails, claiming (rightly, as I understand it) that /Applications/NeoOffice.app/Contents/Library/Spotlight/neolight.mdimporter/Contents/MacOS/neolight is not a suitable image.

This seems to say pretty clearly that when the Spotlight daemon indexes the document on its own it does not use the same plug-in that the mdimport command uses.

At this point I do not have any clever ideas. All I can think of is to ditch NeoOffice, safe boot, try it all again, and repeat as needed.
Comment 10 Tom Wyant 2012-11-28 04:15:56 UTC
After deleting /Applications/NeoOffice.app and /Library/Spotlight/neolight.mdimporter and safe booting, Spotlight did NOT index new .ods or .odt files. The .odt files could be indexed by running mdimport, which said the indexing was being done by /System/Library/Spotlight/RichText.mdimporter. Attempts to hand-index .ods files with mdindex failed, but this time reported an architecture problem with /Applications/LibreOffice.app/Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter

I restored /Library/Spotlight/neolight.mdimporter from Time Machine, without affecting the indexing behavior. But after a safe boot .odt files were indexed on creation. Interestingly, mdimport -d 1 still claimed the indexing was being done by /System/Library/Spotlight/RichText.mdimporter. The .ods files were still not being indexed on creation, and an attempt to force indexing with mdimport still reported an architecture problem.
Comment 11 Don't use this account, use tml@iki.fi 2013-08-06 07:15:19 UTC
LibreOffice can be built as 64-bit code for OS X, TDF just needs to be brave enough to start distributing it as such.
Comment 12 Don't use this account, use tml@iki.fi 2013-08-06 07:27:42 UTC
Probably best to mark this as a duplicate of the generic enhancement request to make (distribute) LibreOffice 64-bit on OS X, even if that is a newer bug.

*** This bug has been marked as a duplicate of bug 58663 ***