[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823 --- Comment #4 from Alfred M. Szmidt --- > Created attachment 9857 [details] > Don't use arbitrary limits. > > The following fixes fixincludes. > > fixincludes/ChangeLog > 2005-09-16 Alfred M. Szmidt >

[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #21 from ams at gnu dot org 2007-10-01 18:04 --- Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared To me it looks like linux.h shouldn't be included It should be included. and gnu.h should be made uclibc-aware.. This would

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #18 from ams at gnu dot org 2006-08-24 18:05 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared I'll try to get around it as soon as I can. Thanks. It has been a month... would be nice if you could look at it soon. Thanks

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #16 from ams at gnu dot org 2006-07-26 15:35 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared I'll try to get around it as soon as I can. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #2 from ams at gnu dot org 2006-07-15 13:45 --- Created an attachment (id=11892) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11892action=view) Fixes #28102 (In reply to comment #1) Why is GNU target including linux.h header at all? TARGET_C99_FUNCTIONS should

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #4 from ams at gnu dot org 2006-07-15 15:17 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Because the rules in config.gcc say so: And that is not why, but that is what is causing linux.h being included? Again why

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #6 from ams at gnu dot org 2006-07-15 15:45 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Only the following code will be duplicated which is hardly any after all: That is from [gcc]/gcc/config/linux.h, I'm talking about [gcc

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #8 from ams at gnu dot org 2006-07-15 16:07 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Can you please just apply the patch and close the bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #11 from ams at gnu dot org 2006-07-15 16:25 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Can you please just apply the patch and close the bug? Why it is not obvious and I say the patch is incorrect. The patch is correct

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #12 from ams at gnu dot org 2006-07-15 16:27 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared Oh did I forget (again) to say you really should be posting patches to the gcc-patches mailing list. Thanks. I'm actually quite aware

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

--- Comment #14 from ams at gnu dot org 2006-07-15 16:55 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared I think we will have to agree to disagree on this, since neither you or I will change our minds. :-) -- http://gcc.gnu.org/bugzilla

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

--- Additional Comments From ams at gnu dot org 2005-10-01 16:46 --- You also have access to a GNU system, GNU/Linux. It is easily testable there. Could you revert the fix? It is better that fails loudly than having a arbitrary limit. I'll see about submiting a proper patch

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

--- Additional Comments From ams at gnu dot org 2005-10-01 16:58 --- Could someone go over these bugs and commit the pending patches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

--- Additional Comments From ams at gnu dot org 2005-08-31 14:56 --- Subject: Re: MAXPATHLEN usage in gcc/ada/*.c This patch is a kludge, GNU does not have any limit what-so-ever on the length of a filename. And it is a horrible kludge, since it is common to have filenames longer than

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

--- Additional Comments From ams at gnu dot org 2005-08-31 15:00 --- Subject: Re: MAXPATHLEN usage in gcc/ada/*.c --- Additional Comments From charlet at gcc dot gnu dot org 2005-08-29 13:14 --- Should not cause compilation error any more. The fix is wrong, GNU doesn't

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

--- Additional Comments From ams at gnu dot org 2005-08-09 17:45 --- Subject: i*86-*-gnu* not enabled in configure.ac The following fixes #21819 (I was requested to send it to gcc-patches@ and java-patches by Andrew Pinski). 2005-08-09 Alfred M. Szmidt [EMAIL PROTECTED

[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c

--- Additional Comments From ams at gnu dot org 2005-08-01 17:48 --- Subject: Re: MAXPATHLEN usage in fortran/{scanner,module}.c So, does GNU define _POSIX_PATH_MAX? No. Does GNU support pathconf()? Yes. I read the other thread where it is suggested that a non-portable

[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c

--- Additional Comments From ams at gnu dot org 2005-08-01 18:24 --- Subject: Re: MAXPATHLEN usage in fortran/{scanner,module}.c So, does GNU define _POSIX_PATH_MAX? No. Then GNU isn't POSIX compliant. Sorry, I meant yes. We do define _POSIX_PATH_MAX. My brain

[Bug libffi/21819] New: i*86-*-gnu* not enabled in configure.ac

: P2 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ams at gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-gnu0.3 GCC host triplet: i686-pc-gnu0.3 GCC target triplet: i686-pc-gnu0.3 http

[Bug java/21821] New: MAXPATHLEN usage in [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc

Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ams at gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

--- Additional Comments From ams at gnu dot org 2005-05-30 14:42 --- Created an attachment (id=8995) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8995action=view) Add i*86-*-gnu* to configure.ac Add GNU to the list of detected systems. 2005-05-30 Alfred M. Szmidt [EMAIL

[Bug libgcj/21821] MAXPATHLEN usage in libjava

--- Additional Comments From ams at gnu dot org 2005-05-30 14:53 --- [gcc]/libjava/java/io/natFilePosix.cc is also broken due to the usage of MAXPATHLEN. -- What|Removed |Added

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

--- Additional Comments From ams at gnu dot org 2005-05-30 14:55 --- Will do. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug java/21822] New: fastjar/jartool.c's usage of MAXPATHLEN

ReportedBy: ams at gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: i686-pc-gnu0.3 GCC host triplet: i686-pc-gnu0.3 GCC target triplet: i686-pc-gnu0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822

[Bug c/21823] New: MAXPATHLEN usage in [gcc]/fixincludes

at gcc dot gnu dot org ReportedBy: ams at gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-gnu0.3 GCC host triplet: i686-pc-gnu0.3 GCC target triplet: i686-pc-gnu0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug libgcj/21821] MAXPATHLEN usage in libjava

--- Additional Comments From ams at gnu dot org 2005-05-30 16:23 --- (In reply to comment #2) Its easy to fix this for natFileChannelImpl.cc. Thank you for fixing it! For natFilePosix.cc it is not so simple - is there a portable alternative to realpath() that does not require

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

--- Additional Comments From ams at gnu dot org 2005-05-26 12:59 --- (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

[Bug libmudflap/21724] New: [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ams at gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

--- Additional Comments From ams at gnu dot org 2005-05-23 17:28 --- Created an attachment (id=8955) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8955action=view) Fix for bug 21724 The following patch fixes the bug. libmudflap/ChangeLog 2005-05-23 Alfred M. Szmidt [EMAIL

[Bug c/21706] New: MAXPATHLEN usage in [gcc]/gcc/tlink.c

. -- Summary: MAXPATHLEN usage in [gcc]/gcc/tlink.c Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P1 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ams at gnu dot org