bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & l


From: Derek Price
Subject: Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Date: Tue, 24 May 2005 17:12:31 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Conrad T. Pino wrote:

>Hi All,
>
>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"
>module.


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
address@hidden, 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
making.

>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
on Windows.

>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.

Cheers,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCk5i/LD1OTBfyMaQRAmpzAKCtKaFhT+SCkBBAyBiZqVdDMh8oqACgngpx
VyNsMm+TNZhbrpY6s6CKUs8=
=BD3e
-----END PGP SIGNATURE-----






reply via email to

[Prev in Thread] Current Thread [Next in Thread]