[Top][All Lists]

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

[Gcl-devel] Re: [sr #104164] Is it possible to call Windows SDK from GCL

From: Camm Maguire
Subject: [Gcl-devel] Re: [sr #104164] Is it possible to call Windows SDK from GCL?
Date: 04 May 2005 09:49:13 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


"Mike Thomas" <address@hidden> writes:

> | The relevant gcc version is 3.4.2 and insertion of a prototype
> | for sdk_hello just before L1 fixes that problem.  Unfortunately
> | the missing initialisation function problem remains in HEAD -
> | perhaps I've called compiler::link incorrectly?.
> Going further into this it looks like I should use the following command:
> >(compiler::link nil "c:/test-hello.exe" "(load
> \"c:/cvs/stable/gcl-2.6.7pre/sdk-hello.o\")" "-luser32" t )

The previous call was correct.  This one will merely link in user32
with ld, and then load sdk-hello.o in the new image, but ld will omit
all symbols not used at link time by the image, which in this case is
all of them.  Which brings up an idea that might be of use in
improving these calls as discussed in my last post -- there is likely
a flag to ld to preserve all symbols, which could be of use in
generating these new relocation sections.

> which does build test-hello.exe but which still has a missing MessageBox
> symbol at load time because the executable only holds onto the symbols in
> user32 which are directly used.
> If I have got the command right and I understand the problem, this suggests
> that for the time being you will need to build GCL from scratch with a
> binding for the various Win32 libraries (such as user32) so that those
> symbols are available when GCL is built and hence at object load time.  If
> you look at the way I did the JAPI binding you will see what I mean.

This is possible, but should not be necessary.  Your previous call
with either :system-p t added to compile-file or setting
compiler::*default-system-p* to non-nil before compiling, should do
the trick.

> The way to fix this is to have some way of searching and selectively
> autoloading from a list of dlls at load time as required by the incoming
> object files (such as, in this case sdk-hello.o).

When you get a moment (this is far less urgent than other stuff), your
thoughts on the link/unexec idea I proposed in the last post would be
much appreciated.  Perhaps if I get a working example on Linux, this
might focus the discussion.  I won't be able to work on thsi for a
while yet.

Take care, 


Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

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