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