[DJGPP+DOS] Issues compiling from source #36
Comments
|
Hello @lighth7015, Are you using |
|
I remember cloning the git repo and having issues cross-compiling it (since DOS doesn't "like" long filenames), I'm going to wait for it to complete and see what the errors are. |
|
And after trying to freshly compile it, this is what I get |
|
Okay, new issue lol, I found those files after some digging around; now it complains about a BUNCH of symbols missing from |
lighth7015
changed the title
|
So |
|
And also, if anybody is wondering why I can't just compile under DOS, |
|
@georgp24 should probably rename his fork of the makefile |
|
It is quite a while ago that I compiled it with djgpp. So I used an older version of djgpp and did not test the latest version of Microwindows if it will compile with djgpp. |
|
I have djgpp set up as a cross compiler, so that should work. |
|
And turning off FT2 makes no difference for compiling landmine. |
That's good news, as we'll need to find/use the files in "drivers/scr_xxx.c, mou_xxx.c, and kbd_xxx.c to get the demo apps linked (see below). but the demo apps give me issues like,
The three references above to 'scrdev', 'kbddev', and 'mousedev' are the screen, kbd and mouse drivers, required when the demos are statically linked to the server, as will be the case on non-multiprocessing OS's like MSDOS. Find the files that worked on the |
FT2 isn't required, and if configured out, all programs will use core text-based or simpler fonts instead. For the first pass, I'd recommend turning off almost all options (see 'src/config' for ideas, all of these are ignored and set separately 'makefile_nr' however).
The DJGPP drivers are in drivers/*dj*.c. I'd recommend using scr_djvesa.c for the screen driver, kbd_dj.c for keyboard, and probably mou_dos.c. @georgp24 will have to say what he used for testing unless that information is already in makefile_nr. I'm sorry for all the errors, DJGPP hasn't been tested in a while and I can't run it over here. |
|
My understanding is that these drivers should be statically linked to libnano-X.a and if you compile the demos you just have to add libnano-X to the command line. Check if these drivers are selected in the config file when you compile libnano-X. If they are not, or the called makefile compiling the files in the drivers directory does not work you may get this problem. |
|
Okay, so a bunch of updates. A handful of missing sources (probably removed and the demos not bothered being sync'd), but |
That file used to define
It would be far easier to unset the external dependencies in the beginning, until you get a working demo program. Nano-X was designed such that this is easily possible. (see
That's too bad, it would make getting this working a lot easier! |
|
Another update, actually I just noticed that it makes no difference really whether it's DOS or linux; I'm getting this for a lot of This is my compile log- |
|
The freetype issues I'm ignoring for the moment, because the more interesting issue is that GCC seems to be emitting |
|
An interesting side-note, it doesn't seem to be inlining it. Like it isn't obeying |
|
Yes, it seems that these calls to __rtdc are being generated by the compilation of the libraries, not in the final link command line you reported above. So look at the full command line of each of the engine/, nanox/ etc library files and see what you find there. It's possible that a DEBUG option turns it on. |
|
Okay, so it was getting squashed my DOS installation of DJGPP. Oops. |
|
Well damn, it actually builds. Now to fix things like FLTK. |
|
In the faq2 file there are instructions how to compile FLTK to use it with libNX11. |
|
So question, can I compile any old X client with this? |
|
Also TinyWidgets is kind of busted. :p |
No, NX11 is tested particularly for FLTK. So you can run most FLTK applications, once you got FLTK running with NX11. NX11 offers a subset of the functions X11 provides. When I tested TinyWidgets it worked quite well. |
|
Like I was interested in seeing if I could port FOX. |
NX11 has a large number of X11 routines mplemented, but few extensions. The easiest way to start is on Linux, and just link a FOX build using '-lNX11 -lnano-X' instead of -lX11. That will give you the list of unimplemented calls. Sometimes it is easy to stub out routines, see 'src/nx11/stubs.c' for the current list. |
You will probably have to write additional functions for NX11, the ones that FOX uses but FLTK does not. |
|
Hum, okay. |
|
Okay, here are the 'undefined' X11 symbols-
Everything else is futzing around with (e.g. fontconfig, pthread) and libc. |
|
How did you determine these 'undefined' X11 symbols? E.g. XCreateGC is implemented in the file |
Looks like that's the complete list without NX11 or X11. Link with '-lNX11 -lnano-X'. |
|
|
Not too bad, really. To sort into categories:
All in all, the biggest porting issue by far is support for the Xft X11 routines. You could possibly try to port Xft over separately, as it rests on top of X11. But as with all things X11, it's ridiculously complicated for what you get. |
|
It would be far easier to start with a less complicated X11 application, IMO. |
|
Fc* is fontconfig, which I'm in the process of compiling. |
|
I am working with djdelorie on freenode for the specifics of his toolchain. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The sources compile fine, however a black screen is displayed when I try and run any of the demo applications compiled.
The text was updated successfully, but these errors were encountered: