[Ecls-list] Compiling Babel with MSVC

[Matthew Mondor]

On Sat, 25 Jun 2011 09:16:12 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> On Sun, Jun 19, 2011 at 11:03 PM, Juan Jose Garcia-Ripoll <
> juanjose.garciaripoll at googlemail.com> wrote:
> 
> > On Sat, Jun 18, 2011 at 6:06 PM, Bill Robinson <airbaggins at 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