Mail Archives: djgpp/2015/06/12/07:19:49
>> I added this to my CFLAGS like CFLAGS = -std=gnu89 -g -Wall -O2 and it
>> still doesn't help. Should I zip up a copy of my DJGGP environment,
> No, definitely not. Check your %DJDIR%\manifest\*.mft files, and report
> back what you have. Hopefully you aren't trying to mix old and new stuff.
> I wouldn't recommend deleting a working setup, but maybe it's too late
> for conservatism. (Besides, you can re-download and re-install older
> versions from mirrors if needed.)
This is a completely new directory for DJGPP I created. It contains no
files from my previous install.
I have one dir on my C:\ as DJGPP and my F:\ drive as DJGPP_205 and
just set my PATHs and DJDIR accordingly.
>> maybe I'm missing something here? The error is pointing to time.h in
>> djgpp itself and I really doubt that time.h would have an issue since
>> it's such a common header to include. It makes me think I added
>> something in the wrong order or wrong version or something to that effect.
> Are you trying to mix /current/ and /beta/? Don't do that. Stick to one
> or the other. Obviously in this case you should maybe just stick to /beta/
> since that's where most 2.05-related stuff is (for now).
>
> I vaguely remember some time.h issue with /beta/ 2.04 regarding _rdtsc(),
> but I think it was fixed later in CVS (and thus in 2.05). Though I
> also kinda doubt that's your problem here. Who knows??
>
>>>> Another reason for
>>>> wanting to try out 2.05 is now the project is getting quite large and
>>>> I'm getting this warning at link time:
>>>>
>>>> "warning: .text: line number overflow: 0x10029 > 0xffff". I guess 2.03
>>>> has smaller limits for compiling a total project size?
>>> Is that (only) with debugging enabled? Yeah, older released (BinUtils
>>> before 2.23 ???) didn't have the COFF relocation extension hack.
>> Upgrading to the latest binutils fixed that issue, thanks for this.
> What Binutils were you using before? Obviously Quake 1 used much older
> tools than we have nowadays. It didn't surpass any COFF limits at the
> time. Well, it was quite small compared to some of the newer .EXEs
> (bloat!). :-)
This is Quake 2, and because the entire game dll is statically linked to
the binary now it's a rather large project.
If you hit those COFF limits will it hurt things? I will try this
bfdsymify.
>> I'm curious about the DX3 and dll capabilities. Will it be able to
>> load/unload? Quake 2 used DLLs for the game, so for now it is
>> hardlinked, but would like to add the possibility to compile other game
>> mods.
> I don't know if it unloads. Honestly, I think it's a bit brittle and
> not widely used. I wouldn't recommend it, esp. if you already have a
> working static library, even if that (in theory) means less flexibility.
> I just don't think it's worth the trouble until you've ironed out
> literally everything else. But hey, it's your funeral. :-)
After these issues are sorted out I would still like some information on
it. We tried an old project, DLM (http://aaganichev.narod.ru/djgpp/),
and during runtime it would
give us this:
DLM -> Exiting due to signal SIGSEGV at
0x0014f59d SYM: _dos_lockmem+0x9 DLM: q2.exe [0xf5000]
possibly because of undefined reference to symbol ‘___djgpp_base_address’
DLM call frame traceback :
0x0014dcaf SYM: _Sys_PageInProgram+0x37 DLM: q2.exe [0xf5000]
0x0014e1c4 SYM: _main+0x18 DLM: q2.exe [0xf5000]
0x0000774e
0x00008b6e
But anyways, one issue at a time here :)
Frank
- Raw text -