Apache OpenOffice (AOO) Bugzilla – Issue 18561
jpeg project detects previously applied patch on re-running dmake
Last modified: 2004-10-05 12:29:58 UTC
Building OOo 1.1RC3 on Windows XP with tcsh. When re-running dmake, the build stops on the following: ============= Building project jpeg ============= /cygdrive/g/oo_11rc3_src/jpeg ------------- cd ./wntmsci9.pro/misc/build && cat ../../../jpeg-6b.patch | tr -d "\015" | patc h -b -p2 && /usr/bin/touch.exe so_patched_jpeg patching file jpeg-6b/jconfig.h Reversed (or previously applied) patch detected! Assume -R? What should I answer, and why is the question posed anyway.
Also: ============= Building project np_sdk ============= /cygdrive/g/oo_11rc3_src/np_sdk ------------- cd ./wntmsci9.pro/misc/build && cat ../../../mozilla-source-M16- stub.patch | tr -d "\015" | patch -b -p2 && /usr/bin/touch.exe so_patched_npsdk patching file mozilla/include/npapi.h Reversed (or previously applied) patch detected! Assume -R? [n]
Also: ============= Building project zlib ============= /cygdrive/g/oo_11rc3_src/zlib ------------- cd ./wntmsci9.pro/misc/build && cat ../../../zlib-1.1.4.patch | tr - d "\015" | p atch -b -p2 && /usr/bin/touch.exe so_patched_zlib patching file zlib-1.1.4/contrib/minizip/unzip.h Reversed (or previously applied) patch detected! Assume -R? [n]
Thanks! I'm not the only one who is getting this! jpeg is not the only project which sees this problem from time to time. I also saw it in: zlib, icu, expat, neon, jpeg or sablot I guess, the reason is that you/me somehow mix FAT32 / NTFS filesystems. (The comment in the following patch is WRONG) FAT32 only stores even seconds in its timestamps, and might be wrong to max. 2 seconds. My TEMP is located on a FAT32 drive, my sources on NTFS and I also got the same problem. I don't get it anymore because I always use the attached patch. Attention, the following patch propably doesn't work for ancient cygwin b2x installations. (Still used in Hamburg?)
Created attachment 8690 [details] Patch for the rebuild problem
Yes, my source tree is on NTFS disk G: and my C: disk is FAT32. I don't have too much experience with patch, how do I apply it?
In your OOo source directory just do a: $ patch -p0 < rebuildprob.diff You can always first try: $ patch --dry-run -p0 < rebuildprob.diff to see if the patch applies without problems. Unfortunately this patch will only help if it already is applied when doing the first build of a project. But then you can rebuild as often as you like. ;-)
I pointed the TEMP and TMP env variables to a directory on my NTFS disk; that also appears to help.
I suspect this solved another problem (issue 18562) for me too. Suggested solutions: - implement Volkers patch in the source code, or - add a warning in the build guide not to have source and temp directories on different file systems
additional 4 seconds per external module should be bearable if they avoid annoing re-patch failurs. if there is a general problem when using temp (fat32) and source (NTFS) it should be notice in the build guides anyway as it may also hit in other places. btw.: i put the target to OOo 2.0 but would also second a change to OOo 1.1.1 if desired...
I'm not sure about the status of this issue, ause can you please enlighten me ?
fixed dependency for additional files
@vq: cannot reach you by mail. please check if the delay/speep is still required at all with the dependency changes made in "ause011".
It is! I'm building m53, sources on NTFS, $TEMP and $TMP pointing to FAT32. Second build: $ build build -- version: 1.115 /w1/SRC680_m53/jpeg ------------- cd ./wntmsci10.pro/misc/build && cat ../../../jpeg-6b.patch | tr -d "\015" | patch -b -p2 && /bin/touch.exe so_patched_jpeg patching file jpeg-6b/jconfig.h Reversed (or previously applied) patch detected! Assume -R? [n]
Argh! Sorry I didn't read carefully enough. > @vq: cannot reach you by mail. please check if the delay/speep is still > required at all with the dependency changes made in "ause011". I didn't use ause011, but slightly patched m53. Is it enough to use tg_ext.mk from ause011 ?
> Is it enough to use tg_ext.mk from ause011 ? No, beside the problem that delay doesn't fly here, it still wants to repatch.
ok, now try this :-) new tg_ext.mk and unitools.mk
Ok, with the new files it works. A nit: --- snip --- Making: ./wntmsci10.pro/misc/jpeg.dpc dmake subdmake=true -f makefile.mk depend=t ALLDPC ------------------------------ No Dependencies ------------- mv ./wntmsci10.pro/misc/build ./wntmsci10.pro/misc/build/jpeg-6b_removeme mv: cannot stat `./wntmsci10.pro/misc/build': No such file or directory rm -rf ./wntmsci10.pro/misc/build/jpeg-6b_removeme --- snap --- This comes from the "#untar" part of tg_ext.mk: +-$(RENAME) $(PACKAGE_DIR) $(PACKAGE_DIR)$/$(TARFILE_ROOTDIR)_removeme +-rm -rf $(PACKAGE_DIR)$/$(TARFILE_ROOTDIR)_removeme that looks a bit strange to me. Why first mv and then rm? And secondly why not add ">& $(NULLDEV)" to silence it?
"rm -rf" on a path that consists of "$(VAR1)$/$(VAR2)" can be ugly when both are not set for any reason ;-)
fixed again to get the CWS integrated
see last comments by vq
.