I tried to compile d1x with gcc 4.0.2 on amd64, and it failed. So I created the following fixes to make this work. I don't know if I did it the proper way, but this works for me (tm)
Created attachment 77382 [details, diff] 20040118-r1.patch d1x-20040118.ebuild -> d1x-20040118-r1.ebuild Changes: - Uses multilib.eclass to safely compile d1x as a 32bit binary - Patches d1x's makefiles to make use of custom CFLAGS (d1x-cflags.patch) - Fixes a small gcc4 compilation error (d1x-gcc4.patch)
Created attachment 77383 [details, diff] d1x-cflags.patch
Created attachment 77384 [details, diff] d1x-gcc4.patch
Was that an "invalid lvalue in increment" error? If it were, you don't have to assign it to new variable, you just can't increment stuff at the same time you're assigning stuff. That is, something like *(((int *)p)) = j; p += sizeof(int); would be a cleaner fix. Otherwise, I'm just talking out of my ass and you should ignore me.
Thanks, I'll use this. As my C knowledge is limited, I tried something that was guaranteed to work, sorry. Someone in the forums suggested to use yasm instead of nasm, which allows producing 64 Bit assamblies. This seemed to work with d2x (i.e. it linked without warnings) but I did not test that yet.
So... this stuff works or no?
Any word on this? I'd like to get this fixed soon in the tree, as I want to mask all of the games packages that fail with GCC 4.1 and don't have fixes coming. Thanks
The successor of this package is d1x-rebirth (bug #154590).
So is this a correct patch? Is it worth fixing?
(In reply to comment #9) > Is it worth fixing? No, it's dead upstream for about 6 years. Use d1x-rebirth.
OK... this has been masked for removal, since d1x-rebirth is in the tree now and works great (at least for me).
