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

Mon Nov 8 00:13:31 PST 2010

I'm familiar with the ELF concept which you stated below. The discussion pointing me in the right direction for Mac OS X is on
http://lua-users.org/lists/lua-l/2008-03/msg00028.html 

The follow up on that message contains the same thing you mention.

I'm going to investigate this a little further, since the COFF and PE files (for MingW and Windows) have to have some kind of 
functionality as well.
As an alternative I also want to investigate, since the issue is deployment, the possibility of so called pack file.
Zip files containing all additional data (even in virtual directories) needed for the program or libraries to run.
This is far more portable than the EMBEDDED_FILE solution. But i will summarize all advantages and disadvantages ..

First I will look at the Mac OS specific solution, without changing to much code ..

Op 8 nov 2010, om 00:54 heeft David García Garzón het volgende geschreven:

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