On Sat, 25 Jun 2011 09:16:12 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll@...> wrote:
> On Sun, Jun 19, 2011 at 11:03 PM, Juan Jose Garcia-Ripoll <
> juanjose.garciaripoll@...> wrote:
> > On Sat, Jun 18, 2011 at 6:06 PM, Bill Robinson <airbaggins@...:
> >> 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
> 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 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):
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...