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

David García Garzón david.garcia at upf.edu
Mon Nov 8 00:42:56 PST 2010


Renaming symbols can be achieved with the objcopy option:
	--redefine-sym oldname=newname

More over if you run on your mac shell:
	echo 'const char mydata[]="mycontent";' > dummy.c
	gcc dummy.c -s  # generates dummy.s
	gcc dummy.cxx -c   # generates dummy.o

- dummy.o can be used to know the file format to use in objcopy with:
	objdump -d dummy.o
- dummy.s has some working assembler for mac, we can use by changing the 
literal by the incfile macro plus changing the .

So both ways, assembler macro and objcopy, are still quite open within 
binutils/gcc world.

David.


A Dilluns 08 Novembre 2010 00:54:32, David García Garzón va escriure:
> 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:
> 
> - renaming the symbols (seems to be objcopy options for that)
>
> - obtaining -O and -B options for a given platform (or fixing the supported
> ones)
> 
> - 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