On Sat, 25 Jun 2011 09:16:12 +0200 Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> wrote:
> On Sun, Jun 19, 2011 at 11:03 PM, Juan Jose Garcia-Ripoll < > juanjose.garciarip...@googlemail.com> wrote: > > > On Sat, Jun 18, 2011 at 6:06 PM, Bill Robinson <airbagg...@gmail.com>wrote: > > > >> Just wanted to bump that I've run into this as well and would appreciate a > >> fix if anyone out there has one. > > > > > > I am working on that. Unfortunately it requires changes in ECL to cope with > > this limitation in Microsoft's compiler. > > > > Ok, I more or less have finished something that works around this problem. > The idea is that compiled data is no longer stored as a C string, but rather > appended to compiled files and loaded using mmap() or open()/read() by ECL > itself. > > The only problem so far is standalone programs. Unlike in FASL files, in > this case it is _very_ hard to find out the place where compiled data > resides (the executable file), because there is no portable way to do that: > > - argv[0] is not guaranteed to keep the name of the executable > - the file itself may be renamed or moved > - in some systems (embedded systems, phones, etc) there might not be any > notion of file system at all. > .. > > Help would be very welcome in solving this problem. Perhaps that another issue would arise with static executables? I remember a similar problem with glibc where static linking was problematic as even static programs would need to find the dynamic library to mmap it... Is this to be able to have a large amount of static read-only data available at runtime? If so, perhaps that another solution would be to produce object files out of binary files at build-time and link those object files along with the program? I'm not sure how portable this is, but I've done that using objcopy on NetBSD, Linux and cygwin->mingw. For instance (see RAWOBJS related code): http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/~checkout~/mmondor/mmsoftware/mystic_ships/client/GNUmakefile?rev=1.1;content-type=text%2Fplain An alternative would be generating C files filled with large arrays (not necessarily strings), which would get compiled as object files containing the data, then linked with the final objects... -- Matt ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
