[clam-devel] Mac OS X: NetworkEditor not building (r14492)

[johnbeuving]

I asked around and have looked in the most portable way for using the CLAM_EMBEDDED_FILE macro.
Summarized the case is that every binary output format (ELF,COFF,MACHO,PE ..) use different mechanisms for embedding binary files into the final binaries.
The current solution is to direct through assembly to create a new section in the binary executable or library.

The only way I found to do this for the Mac OS X platform is to use a sectcreate linker option to embedded the file into the binary.
Some glue code is required to get the correct section pointers. Ik have played around with this and seems like a good solution.
The main disadvantage is that the linking is different for the different platforms.

Another way, which is also more portable, is to load the file from the original file. So don't add the file to binary.
This has as main disadvantage the deployment of the package during install. But could be a good alternative as a fallback.
           
I prefer to implement both scenario's, altough it has a higher risk, but in the end CLAM is portable again.
My main development platform will be OS X. I tried playing around with VMWare Fusion, but the audio playback is just to slow.

I will try to create a patch for the OS X platform to create the linker options and the glue file.



Op 2 nov 2010, om 22:35 heeft johnbeuving het volgende geschreven:

> I'm using both macports and Xcode. But i'm currently focusing on the macports version.
> I already have tried to disable the macro in the error case and of course compilation succeeded.
> I didn't continue from there since I hoped for a better workaround.
> 
> I will have a look if there would be a solution for a embedded file solution for mac and post it here.
> 
> John
> 
> Op 2 nov 2010, om 21:44 heeft David García Garzón het volgende geschreven:
> 
>> A fast workaround would be substituting CLAM_EMBEDDED_FILE uses by a const 
>> char * variable of the same name (first parameter of the macro) initialized to 
>> an empty "" string. Not sure of the runtime effects, (Xavi? any idea?) but, at 
>> least i will compile.
>> 
>> Because we are using embedded files in NetworkEditor and in many other nice 
>> places such as ladspa/lv2/vst plugins i guess we should find a proper solution 
>> for mac: finding the assembler needed in mac to embed a file into the binary. 
>> I have no idea of which assembler or binary format is used. I guess it is 
>> something related to binutils. Something to try would be forcing the use of 
>> one of the two existing alternatives (ELF and COFF) just to see whether by 
>> chance it works.
>> 
>> Which tool chain are you using? macports? XCode?...
>> 
>> David.
>> 
>> 
>> On Tuesday 02 November 2010 16:35:08 johnbeuving wrote:
>>> Hi,
>>> 
>>> I'm trying to build the chordata application for Mac Os X. To do this I
>>> first had to build and install the CLAM libaries. Not a big problem there.
>>> Then I found out that the chordata application was dependent on the
>>> NetworkEditor. The NetworkEditor depends on an EmbeddedFile implementation
>>> int the file src/NetworkUpgrader.cxx of the NetworkEditor sources. The
>>> exact error message is from the header file:
>>> 
>>> EmbeddedFile.hxx:40:2: error: #error "No support for embedded files in your
>>> platform"
>>> 
>>> This error is directed when neither __ELF__ and __MINGW32__ (coff binary)
>>> are defined. I really wanted to look for a workaround but somehow there is
>>> a hard requirement for the EmbeddedFile.
>>> In which direction should i look for a solution to get the NetworkEditor
>>> building and also the chordata. ??
>>> 
>>> John D
>>> 
>>> _______________________________________________
>>> clam-devel mailing list
>>> clam-devel at lists.clam-project.org
>>> http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.org
>