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

David García Garzón david.garcia at upf.edu
Sun Nov 7 15:54:32 PST 2010


I just realized i started a search for such a command some time ago and I 
found objcopy from gnu binutils. You can use it like this: 

objcopy -I binary -O elf32-i386 -B i386 --rename-section 
.data=.rodata,alloc,load,readonly,data,contents myfile.txt myfile.o

You obtain an object (.o) file with the data as a symbol named: 
binary_myfile_txt_start
binary_myfile_txt_end
binary_myfile_txt_size
(any non alphanumeric symbol, including path slashes seems to be turned into 
underlines)

I discarded it then because current implementation also provides that and it 
didn't require working on the scons. The remaining aspects to investigate are:

- obtaining -O and -B options for a given platform (or fixing the supported 
ones)

- renaming the symbols (seems to be objcopy options for that)

- coordinate all that from scons

If you want to help on that you are welcome because we are quite busy in 
other areas. A first step could be knowing which are the flags for mac.

David.


A Diumenge 07 Novembre 2010 21:16:15, David García Garzón va escriure:
> 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.or
> > >>> g
> > 
> > _______________________________________________
> > 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



More information about the clam-devel mailing list