tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] dynamic library - embedded header, object, library...


From: Jared Maddox
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object, library....files
Date: Wed, 16 Apr 2014 00:15:36 -0500

Happily, it appears that the cat did NOT send this email for me.

> Date: Tue, 15 Apr 2014 17:58:57 +0200
> From: Josip Habjan <address@hidden>
> To: address@hidden
> Subject: [Tinycc-devel] dynamic library - embedded header, object,
>         library....files
> Message-ID:
>         <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Is there a chance to add a simple function that will allow users to load
> all required files from memory? For instance: I made a .NET wrapper for
> tcclib and I have all 'lib' and 'include' files compiled in a single .NET
> dll as embedded resources. Now, I don't want to export embedded files out
> from the dll to disk, and then run compiled, instead i would like compiler
> to ask me where he can find requested file. (In my case I want it to be
> read from memory).
>
> What I'm thinking is some function that will allow file redirection. This
> would be easy for non windows systems which supports "fmemopen" function as
> they can easily redirect some file request to the file descriptor from
> memory returned by "fmemopen". For windows users the only option is a
> memory buffer.
>

Look up "virtual io tcc", or look at this (
http://lists.nongnu.org/archive/html/tinycc-devel/2013-01/index.html )
page, starting around January 10th. I don't believe such a facility
was ever accepted into a release candidate, but I think it was on a
"not enough requests" basis rather than anything else. Then again, I
didn't review all of those emails.

On a slightly separate note, this is the second question that seemed
relevant to "virtual io" that I REMEMBER from as many weeks (the other
was in a direct email). I think that there really is enough reason to
add this sort of "glue layer" into TCC, though I also wonder if this
should be forcibly delayed until after the "globals removal" work has
been completed and merged, since it would probably be wise to allow
individual states to be associated with individual individual IO
wrappers.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]