X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: rugxulo AT gmail DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: p7zip 9.20.1 cross-compiled by Rugxulo Date: Wed, 22 Aug 2012 15:05:13 -0700 (PDT) Organization: http://groups.google.com Lines: 101 Message-ID: <0767c622-615f-42ed-bb35-ebeef4268974@googlegroups.com> References: NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1345673519 2825 127.0.0.1 (22 Aug 2012 22:11:59 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Wed, 22 Aug 2012 22:11:59 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse AT google DOT com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 Bytes: 5359 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q7MMU2SI019065 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hi, On Tuesday, August 21, 2012 1:52:12 AM UTC-5, Rod Pemberton wrote: > > Elsewhere, Rugxulo posted p7zip 9.20.1 cross-compiled for DOS using DJGPP: > > http://www.bttr-software.de/forum/forum_entry.php?id=11710 I really only expected a few random testers there. No offense to this group, but usually they ignore requests and are too busy with other things. BTW, this was really just piggybacking atop Khusraw's previous build (two years ago!) of 9.13 with fixed FSU Pthreads. (GNU pth + Watt-32 doesn't work so well anymore.) > But, he may need our help: > > There could be many locations that need changing to fix path separators in > p7zip 9.20.1 for DOS. But, I'd think that only the separators already > adjusted for Win32 would need to be added for DJGPP. I.e., I think for > Win32 it converts between *nix-style slashes and Windows. A search > finds only four p7zip files where the separator is adjusted in Win32 #ifdef > sections: > > FilePathAutoRename.cpp in AutoRenamePath() > 7zUpdate.cpp in GetReverseSlashPos() > Wildcard.cpp > Types.h > > I'd guess that adding DJGPP to those Win32 #ifdef's would fix the problem. No, apparently those alone weren't enough. (But yes, I changed a few "#ifdef _WIN32" to "#ifdef DOSWIN".) > This is just like you did for your other fixes in the diff files. If it > doesn't, try fixing the '/' in FileFind.cpp and FileDir.cpp. Yes, those had to be fixed too. Somebody forgot to use the path separator defines from Types.h and instead relied on hardcoded constants. Which actually worked via the typical *nix way supported by DJGPP, thankfully, but it's still way less than ideal for DOS users. > Also, you'll probably need or want some of DJGPP's CRT0 flags to be added in > files with C's main(): > > #ifdef DJGPP > #include > int _crt0_startup_flags = _CRT0_FLAG_USE_DOS_SLASHES; > #endif I wouldn't have even wanted to do this much (and I was trying to be careful not to break anything), but the sfx didn't like the previous changes (which otherwise seemed to work fine). So I did add this one bit just to make that work again, apparently. Perhaps there was a better fix, but I dunno. > Those will help pass DOS path's correctly. It's honestly too dangerous to mess with. I don't want to call p7zip a sloppy port (from Win32 to POSIX), but it's not something I'm comfortable with. Anyways, even now, it still won't recognize a file such as BLAH.7Z, but blah.7z works fine (go figure). And that's without "preserving" or "keeping uppercase" anything! So I dunno, minor nit. main() was actually (barely) in Main.cpp and (mostly) MainAr.cpp. > HTH and hope you see this, Yes, it did help, not totally, but very very close. Thanks!! Though it's still not totally perfect. For instance, I still haven't bothered looking for or fixing the temporary file generation (e.g. updating existing archive), so it assumes LFNs, e.g. blah.7z.tmp , which obviously doesn't work in SFN. A stupid workaround is to rename blah.7z to blah [sic], then do "7za d -r blah. *.c" [sic], and it should delete or update correctly (assuming you don't want to just use DOSLFN). The other problem was probably an obscure compiler optimization bug. It was crashing on -mx8 and -mx9 when compressing .EXE files, so I figured it was something in BCJ filter. Deleting those BCJ*.o files and recompiling with -Os seemed to work around the issue for now. Anyways, I uploaded the new .EXEs to iBiblio (again), but I've kept the older one just in case I made it worse somehow. FreeDOS has already had bug reports on the fact that 9.13 only worked with *nix slashes '/', but up until now, I could never (successfully) fix it. (And I doubt upstream cares, but who knows.) P.S. Juan, if you're reading this, XZ 5.0.4 is out. Somebody (Lasse?) apparently compiled XZ.EXE (only!) 5.0.4 for DJGPP already. But considering newer 5.1.2 alphas are in the works, you may want to wait a few weeks so as not to waste time on a (soon to be updated) port. http://tukaani.org/xz/ http://tukaani.org/xz/xz-5.0.4-dos.zip 310272 2012-06-22 17:18 XZ.EXE