Rebuild XCross binaries?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Rebuild XCross binaries?

singmajesty
Hi!

I've been taking a look at the XCross library -- it's very cool! However,  
I'm not quite sure how the binaries were created.

In xcode.c, I can see this code:



extern void std_main();
extern void regexp_main();
extern void zlib_main();
extern void ui_main();

void neko_standalone_init() {
        sys_init();
        std_main();
        regexp_main();
        zlib_main();
        ui_main();
}



... but I don't understand how the std, regexp and zlib NDLLs are being  
linked into the final binary. It seems that it does not try to use dlopen  
anymore, because it won't find nme.ndll if it is in the same directory.

Please tell me it is simpler than this?  
http://gamehaxe.com/2007/12/03/stand-alone-neko/

I'd love to be able to statically link, but as a simpler approach, should  
I be looking at "nekotools boot", to see how that works, so I can see  
about merging a Neko VM for each platform with the Neko application, still  
requiring external NDLLs?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Rebuild XCross binaries?

singmajesty
I've made some progress. I think that cross-compiling is working now...  
maybe? :)

I'm writing neko.exe and MyApplication.n into the same file, with "NEKO"  
and the length of neko.exe at the end

When I run the resulting executable, it works, but I'm not sure if this  
would work on a system without Neko installed? I have std, regexp, nme,  
etc in the same directory.

Let me know if you think there's something different I should be doing to  
make this work.

Thank you!



On Tue, 11 Oct 2011 12:58:26 -0700, Joshua Granick  
<[hidden email]> wrote:

> Hi!
>
> I've been taking a look at the XCross library -- it's very cool!  
> However, I'm not quite sure how the binaries were created.
>
> In xcode.c, I can see this code:
>
>
>
> extern void std_main();
> extern void regexp_main();
> extern void zlib_main();
> extern void ui_main();
>
> void neko_standalone_init() {
> sys_init();
> std_main();
> regexp_main();
> zlib_main();
> ui_main();
> }
>
>
>
> ... but I don't understand how the std, regexp and zlib NDLLs are being  
> linked into the final binary. It seems that it does not try to use  
> dlopen anymore, because it won't find nme.ndll if it is in the same  
> directory.
>
> Please tell me it is simpler than this?  
> http://gamehaxe.com/2007/12/03/stand-alone-neko/
>
> I'd love to be able to statically link, but as a simpler approach,  
> should I be looking at "nekotools boot", to see how that works, so I can  
> see about merging a Neko VM for each platform with the Neko application,  
> still requiring external NDLLs?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Rebuild XCross binaries?

Nicolas Cannasse
In reply to this post by singmajesty
Le 11/10/2011 21:58, Joshua Granick a écrit :

> Hi!
>
> I've been taking a look at the XCross library -- it's very cool!
> However, I'm not quite sure how the binaries were created.
>
> In xcode.c, I can see this code:
>
>
>
> extern void std_main();
> extern void regexp_main();
> extern void zlib_main();
> extern void ui_main();
>
> void neko_standalone_init() {
> sys_init();
> std_main();
> regexp_main();
> zlib_main();
> ui_main();
> }
>
>
>
> ... but I don't understand how the std, regexp and zlib NDLLs are being
> linked into the final binary. It seems that it does not try to use
> dlopen anymore, because it won't find nme.ndll if it is in the same
> directory.

We don't link the ndll since a ndll is a dynamic library. You then need
to directly link all the .o (.obj on windows/msvc) together in your
xcross binary.

See Makefile.real which contains the list of all modules that get linked.

Please notice also that on Windows you cannot use a NDLL : this is
because each Windows NDLL references the Neko API it uses explicitly as
"neko.dll". You could change that to use "xcross.exe" but that would
break as soon you rename your executable. There might be a solution to
this, not sure about it.

But anyway if you want to have a single-file executable then you need to
link NME statically as well.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Rebuild XCross binaries?

singmajesty
What about a standalone executable, that still has supporting libraries?

I wrote "neko.exe" and "ApplicationMain.n" together, with a "NEKO" bit at  
the end with the length of neko.exe. Is this the right method for creating  
a single executable that can run on machines without Neko installed? For  
Windows, Mac and Linux?

Thanks!



On Wed, 12 Oct 2011 01:05:02 -0700, Nicolas Cannasse  
<[hidden email]> wrote:

> Le 11/10/2011 21:58, Joshua Granick a écrit :
>> Hi!
>>
>> I've been taking a look at the XCross library -- it's very cool!
>> However, I'm not quite sure how the binaries were created.
>>
>> In xcode.c, I can see this code:
>>
>>
>>
>> extern void std_main();
>> extern void regexp_main();
>> extern void zlib_main();
>> extern void ui_main();
>>
>> void neko_standalone_init() {
>> sys_init();
>> std_main();
>> regexp_main();
>> zlib_main();
>> ui_main();
>> }
>>
>>
>>
>> ... but I don't understand how the std, regexp and zlib NDLLs are being
>> linked into the final binary. It seems that it does not try to use
>> dlopen anymore, because it won't find nme.ndll if it is in the same
>> directory.
>
> We don't link the ndll since a ndll is a dynamic library. You then need  
> to directly link all the .o (.obj on windows/msvc) together in your  
> xcross binary.
>
> See Makefile.real which contains the list of all modules that get linked.
>
> Please notice also that on Windows you cannot use a NDLL : this is  
> because each Windows NDLL references the Neko API it uses explicitly as  
> "neko.dll". You could change that to use "xcross.exe" but that would  
> break as soon you rename your executable. There might be a solution to  
> this, not sure about it.
>
> But anyway if you want to have a single-file executable then you need to  
> link NME statically as well.
>
> Best,
> Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Rebuild XCross binaries?

Gamehaxe
Hi,
One thing to watch out for is that this process interferes with
the nme windows exe icon setting code, which also messes with existing
exes.  May take a little effort to get right.
Are you thinking in terms of NME?  because there is not much
point building a single exe when you also need assets and plists etc.
You may as well just copy the appropriate neko exe without modification.
This would still be cross compilation (not sure how easy it will
be to set the windows icon from a linux box though)

Hugh

> What about a standalone executable, that still has supporting libraries?
>
> I wrote "neko.exe" and "ApplicationMain.n" together, with a "NEKO" bit  
> at the end with the length of neko.exe. Is this the right method for  
> creating a single executable that can run on machines without Neko  
> installed? For Windows, Mac and Linux?
>
> Thanks!
>
>

--
haXe - an open source web programming language
http://haxe.org