[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & l
Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Tue, 24 May 2005 17:12:31 -0400
Mozilla Thunderbird 1.0.2 (Windows/20050317)
-----BEGIN PGP SIGNED MESSAGE-----
Conrad T. Pino wrote:
>The new module "lib/canonicalize.c" fails to compile because it references
>the symbolic error "ELOOP" which Windows does not define.
>The new module "lib/canonicalize.c" calls the "lstat" function and there
>is no prototype and no implementation on Windows platform we support.
>We use "CVS_LSTAT" macro in the "src" directory which maps to "wnt_lstat"
>which we implement in "windows-NT/filesubr.c". We also have "lib/stat.c"
I've just checked in a patch which replaces all references to "CVS_STAT"
with "stat" and all references to "CVS_LSTAT" with "lstat". I've made
changes to the GNULIB modules to support this and submitted the changes
back to GNULIB. I also checked them into CVS to speed up our resolution
of this issue.
>Currently the Windows build doesn't use the "lib/stat.c" module.
I think it shouldn't. the GNULIB stat and lstat modules replace stat
and lstat when some specific UNIX bugs are encountered, but rely on the
underlying stat & lstat to work. The simplest thing to do at this point
would probably just be to #define stat wnt_stat and #define lstat
wnt_lstat in windows-NT/config.h.in.in.
If you are feeling particularly motivated to ramp up the Windows support
in GNULIB, you could try to package the work wnt_stat and wnt_lstat do
on Windows into the GNULIB stat module and submit the whole back to
firstname.lastname@example.org, but it shouldn't be necessary and there has been
serious resistance there to adding anything to GNULIB modules like the
GetUTCFileModTime Windows system call that check_statbuf appears to be
>The questions raised appear to be:
>1. Where should an "ELOOP" definition be placed?
>2. How should the "ELOOP" value be selected?
These are good questions. Is there any similar errno macro on Windows
to ELOOP? ELOOP happens on UNIX when a program encounters symbolic
links like this:
ln -s dir2 dir1 (dir1 --> dir2)
ln -s dir1 dir2 (dir2 --> dir1)
and then a function is asked to evaluate a path containing one of these
elements, like `./dir1/sdir/file'. Is something similar possible with
Windows links? If so, there should be a "correct" substitute for ELOOP
>An incomplete patch set to the Windows build files is below to allow the
>Visual Studio IDE build to complete up to the EXE link. I plan to commit
>a complete fix once a consensus on the above issues emerges.
The ELOOP definition in your patch may not be the best, but your build
file changes should be fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----