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

[David García Garzón]

I am glad that you did that research. We have no mac available at the moment 
for experimenting so your feedback is very welcome.

A Diumenge 07 Novembre 2010 13:21:20, johnbeuving va escriure:
> 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. 

Which are those formats? When does mac use one or another? which is the 
one for macports, our main target in mac? Any documentation we could 
scratch?

> 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.

We started using files, but we moved to embedded files because they were 
more convenient to deploy. If we think in multiplatform it's better having a 
centralized place where to place the non-portable code to embed a file than to 
do path management everytime we want to access a file. That's if we have 
such code for each platform.

Even though, if we don't have such a code for mac, but we have a command 
to generate c++/asm code or even a compiled object which contains the data 
as a given symbol, we can do some SConstruct magic to keep the same code 
as now for any platform. Let the macro just declare the variable and let SCons 
scan files for the macro to generate the proper targets and building them 
using that command. I already had a pending task to create an scons scanner 
because of the dependencies, but if the scanner has to generate new actions, 
for a given platform that's ok too.

> 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.

Nice having a working piece of code would be a nice start.

David.



> 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
> 
> _______________________________________________
> clam-devel mailing list
> clam-devel at lists.clam-project.org
> http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.org

-- 
David García Garzón
(Work) david dot garcia at upf anotherdot edu
http://www.iua.upf.edu/~dgarcia