please bump
Created attachment 80547 [details] dosemu-1.3.3.ebuild 1.3.3 includes support for 64 bit processors and uses an updated freedos version. I ignored the 64 bit enhancements since I use x86 and traditionally, this program was marked only ~x86. However, the maintainer may wish to review configure.ac and see. Also, I updated one patch file for configure.ac and removed the need for broken links. I don't see the problem it corrected anymore. I also made small changes to the ebuild in the way it handled freedos and included some additional documents for /usr/share/doc. This ebuild requires the patch file which is also uploaded.
Created attachment 80548 [details, diff] dosemu-1.3.3-configure.ac.patch configure.ac patch file to remove changes to CFLAGS and architecture detection. Hope I did it right :)!
FWIW I am getting DPMI unhandled exception 0d errors in routine programs I had used before. Don't know exactly why yet. Could be freedos. Need to investigate.
Definitely a problem witn 1.3.3. DPMI does not work. My rec is to stay with 1.3.2 unless you don't need DPMI and wait for upstream.
http://sourceforge.net/tracker/?group_id=49784&atid=457447 Forget it. Won't work with DPMI for the time being. BTW, something is wrong with my ebuild. There is a tmp directory in /usr/share/dosemu/freedos which symlinks to /tmp. Don't know why. Maybe that's what the broken links patch was for. Also pulled CVS code to test, but same result. Reported upstream.
OK, the DPMI problem is NOT a dosemu bug. It is EITHER: 1) a problem with the configure.ac patch, or 2) /etc/dosemu not being cleaned out, or 3) not starting with a clean ~/.dosemu drive. I tested this by compiling the program clean outside of gentoo and installing in /usr/local. It works fine. Next, I removed the patch from the 1.3.3 ebuild and the product again runs fine. So, somewhere, I screwed up! Hanno, maybe you can take a look and see where the problem may be? I'm just happy to have it working. To watchers here, simply comment out the EPATCH line in the attached ebuild and you should have no DPMI troubles.
Created attachment 80805 [details] dosemu-1.3.9999.ebuild In case anyone is interested, this ebuild pulls the latest cvs code. It has no patches, and therefore works fine. Still don't know if this is correct, but, as they say, "works for me!"
FYI: from dosemu maintainer/developer: >Comment By: Bart Oldeman (bartoldeman) snip... It would be useful to know what the exact CFLAGS were that were used, so we can perhaps make DOSEMU more resistent against (possible future) GCC optimizations: these may be pointing to otherwise hidden bugs. But one flags that should certainly *not* be removed is -fno-strict-aliasing --- I do know that all CFLAGS were removed in configure.ac and -fno-strict-aliasing is added to the optimizations flag. However, when I removed the CFLAGS at the end of the patch, the opt never got applied. By putting CFLAGS=${OPT} in at the end, dosemu compiles fine. The patch needs some work, so although I am uploading a new version of the patch, I hope the maintainer will redo it so it proper. Just remember, -fno-strict-aliasing must be set.
Created attachment 80821 [details, diff] dosemu-1.3.3-configure.ac.patch Please uncomment the #EPATCH lines in the ebuilds if you want to apply. However, the program run fine using native settings. Because this is an emulator, an argument could be made to let dosemu's flags be. Recall also, it has 64 bit settings too. AFAIK, I see no reason to tweak the settings in this program. JM2C.
Lastly, because the freedos tarball gets expanded, unmerge does not clean out /usr/share/dosemu properly. 1.3.3 remnants after unmerge. mars dosemu # ls -l /usr/share/dosemu total 8 -rw-r--r-- 1 48501 50784 737 Jul 10 2004 FDchange.log -rw-r--r-- 1 48501 50784 2793 Sep 26 2003 README.bindist drwxr-xr-x 3 48501 50784 72 Feb 27 04:39 freedos mars dosemu # ls -l /usr/share/dosemu/freedos total 0 drwxr-xr-x 2 48501 50784 48 Sep 19 2003 tmp In the CVS version tmp is a symlink to /tmp. It probably should not even be there?
FYI: from dosemu maintainer: Comment By: Bart Oldeman (bartoldeman) Date: 2006-02-28 07:23 At least in the past -O3 was also problematic, in particular its -finline-functions, but I don't think it is anymore. I think that anyone who actually changes configure.ac should be very careful about gcc options. In particular in your case gcc generated warnings about dpmi.c. In the long term it's useful to make dosemu -fstrict-aliasing safe, but that's a lot of work; there are lots of dodgy pointer casts. I already committed a change to cpu.h in CVS that fixes a lot of these, and it happened to fix the DPMI crash, but that change is by no means sufficient, and more bugs may show up.
Anyone looking at this?
hanno, I know you are alive :P Please get this done or give someone else the permission to do so
What versions of software do you need to compile this? I tried it with autoconf 2.60 and it failed, then I downgraded that and autoconf-wrapper to a previous version, but the configure still failed. :( This is the relevant part of my emerge --info: Portage 2.1.1_pre1-r5 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-emission4 i686) ================================================================= System uname: 2.6.16-emission4 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.12.1 ccache version 2.4 [enabled] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.16 ACCEPT_KEYWORDS="x86 ~x86" Do I need to downgrade automake as well? Thanks.
Created attachment 95887 [details] dosemu-1.3.3.ebuild Hi, can you please all try this? Should workaround the autoconf-issue, I've changed the fd-tarball-handling to pass it to configure instead of copying it manually. It "worksforme", but I didn't really get all those issues we had in the past with this, so I'd like to have some testers. I'd also like to wait till someone packages an freedos-1.0-tarball before putting it into the tree.
added for now, no amd64 yet, doesn't build plugins.
