Please do not use MAXPATHLEN, it is a arbitrary limit, and is not defined on GNU. Currently gcc 4.0.0 is unbuildable on GNU since [gcc]/gcc/tlink.c assumes that MAXPATHLEN is defined. Please do not use these kind of limits in GNU programs. Suggested fix is to declare initial_cwd as: char *initial_cwd; and then instead of doing: getcwd (initial_cwd, sizeof (initial_cwd)); do: initial_cwd = getcwd (NULL, 0); Note: getcwd (NULL, 0) is a GNU extention, and might not be available on non-GNU platforms. (End of Note) Sorry for not supplying a patch, happy hacking.
What about using PATH_MAX which is part of the POSIX standard?
Subject: Re: MAXPATHLEN usage in [gcc]/gcc/tlink.c "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | What about using PATH_MAX which is part of the POSIX standard? I think the point was about arbitray limit; and as far as I can tell GNU does not claim to be POSIX, does it? ;-) -- Gaby
Like most POSIX limits PATH_MAX may not be defined if the actual limit is not fixed.
(In reply to comment #3) > Like most POSIX limits PATH_MAX may not be defined if the actual limit is not > fixed. Correct, and GNU doesn't have such a limit for the length of filenames, the number of arguments passed to a program or the length of a hostname. And probobly a whole bunch of other things that have slipped my mind right now. All of this is perfectly compliant with POSIX.
Confirmed.
Created attachment 9447 [details] Poposed patch for gcc/tlink.c Index: gcc/ChangeLog 2005-08-05 Alfred M. Szmidt <ams@gnu.org> * tlink.c (tlink_init): Use dynamic allocation for INITIAL_CWD.
libiberty actually already has its own powerful getpwd () Attaching patches currently fails, I'll try to submit later if I remember (else remind me).
Created attachment 16643 [details] better patch
Fixed on trunk as rev142043.