RE: binutils status ?
> On Thu, May 23, 2002 at 11:50:20PM +0200, Ralf Habacker wrote: > >If have tested this patch with my cygin /bin dir (345 files) and rebinded kde > >2.2.2 dll's and exes (335 files) and have got no problems with > printing import > >tables. > > > >2002-05-23 Ralf Habacker <[EMAIL PROTECTED]> > > > > * peXXigen.c (pe_print_idata): fixed some seg faults > > on printing import tables with auto-imported symbols. > > I have applied this patch, with Nick's permission. > > The patch did apply cleanly but I did have to do a substantial amount of > cleanup on spacing issues. The indentation was really off, AFAICT. > Thanks for this hint. I'll review the documentation to see what I have done wrong, so the next patches should be better in this way. Regards Ralf
Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
I am trying to install prc-tools on my WinXP machine, using cygwin setup 2.218.2.9. I select the "install from internet" button, to install to c:\cygwin, local package directory c:\deleteme, Direct connection, choose ftp://ftp.sunsite.utk.edu and http://prc-tools.sourceforge.net ads download sites. When I click the Next button, the program successfully downloads setup.ini. Then an error window with the title "Parse Errors" pops up, with a whole set of errors. (null) line 1: parse error, unexpected $undefined. (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 1: unrecognized line in setup.ini headers (do you have the latest setup?) (null) line 2: unrecognized line in setup.ini headers (do you have the latest setup?) and so forth until the error window is full. Then the cygwin setup window shows up, but the prc-tools options are not available under the Devel group. I have succesfully installed prc-tools using setup on my Win98 machine using the same version of setup and the same mirrors. Any thoughts? Thanks in advance, Carl Sorensen
Re: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
On Thu, May 30, 2002 at 09:02:12AM -0600, Carl Sorensen wrote: > I am trying to install prc-tools on my WinXP machine, using cygwin setup > 2.218.2.9. [...] > (null) line 1: parse error, unexpected $undefined. > (null) line 1: unrecognized line in setup.ini headers (do you have the > latest setup?) Yes. This was happening intermittently while I was updating our little setup.ini, and would go away with random changes to the file, or even if I just saved it again. Or something. I couldn't figure out what was going on. I thought the problem had gone away, but now that it's gone live, I've been getting a few reports that it's failing for some people. Intermittently. (Uninitialised variable in the parser maybe?) The setup.ini in question is at http://prc-tools.sourceforge.net/install/setup.ini in case any experts can see what dumb mistake I've made. I've only got HEAD setup.exe sources, I haven't yet pulled down the current branch ones to try to figure out what the error messages are trying to tell me. I guess I should. Incidentally, contrary to the example at the end of http://sources.redhat.com/cygwin-apps/setup.html, my trial and error found that the quotation marks in sdesc were not optional. If so, maybe the example needs updating. John
Re: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
The error messages which Carl saw come from iniparse.cc, which in turn is produced from the parser definition in iniparse.y. >From the definitions in iniparse.y it is clear that the sdesc and ldesc arguments have to be put in quotes in order to be recognized as a single token. So, as John said, the example at the bottom of the page (http://sources.redhat.com/cygwin-apps/setup.html) is wrong and should be corrected. (Rob, are you listening ?) One thing which maybe could cause problems is the accomodation of the md5 checksum support in setup.ini. See the description on http://sources.redhat.com/cygwin-apps/setup.html. Adding md5 checksums to the setup.ini for prc-tools could be a good idea anyway in order to be compatible with future versions of setup. An other thing which might be going on is that after the download from setup.ini from sourceforge (via http) the file does not get properly closed, and/or does not get the right permissions to be opened again for reading by the parser. All these permission problems do not exist on Win9x. One thing Carl could try is to use the latest setup snapshot on http://cygwin.com/setup-snapshots/. The latest one right now is setup-2.249.exe. See if the problem is still there on XP with that version. I myself have no access to an XP machine, so I cannot help any more with this. Hope this sheds a little more light on the problem. Ton van Overbeek
Re: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
On Thu, May 30, 2002 at 06:32:19PM +0200, Ton van Overbeek wrote: > From the definitions in iniparse.y it is clear that the sdesc and > ldesc arguments have to be put in quotes in order to be recognized as > a single token. [...] > One thing which maybe could cause problems is the accomodation of the > md5 checksum support in setup.ini. All of that, but the errors occur right at the start of the file, in the headers part. So problems down in the packages part can't be it, because they haven't been parsed yet. I've been reading more about what $undefined means to bison (I think it means the lexer returned something that isn't listed in %token in iniparse.y). With that in mind, I've nuked the comments from the top of the file just in case, but I really don't think it should make a difference. > An other thing which might be going on is that after the download > from setup.ini from sourceforge (via http) the file does not get > properly closed, and/or does not get the right permissions to be opened > again for reading by the parser. All these permission problems do > not exist on Win9x. Hmmm... this seems like a possibility. The only reports of this have been on Windows 2000 and XP. (An error-induced EOF would probably look like $undefined in the header part.) John
Re: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
On Thu, May 30, 2002 at 06:32:19PM +0200, Ton van Overbeek wrote: >The error messages which Carl saw come from iniparse.cc, which in turn is produced >from the parser definition in iniparse.y. > >>From the definitions in iniparse.y it is clear that the sdesc and ldesc arguments >have to be put in quotes in order to be recognized as a single token. >So, as John said, the example at the bottom of the page >(http://sources.redhat.com/cygwin-apps/setup.html) is wrong and should be >corrected. (Rob, are you listening ?) What specific example are you looking at? % grep sdesc setup.html sdesc: "some text" sdesc and ldesc are both mandatory fields for the sdesc field is required for correct operation of setup.exe. sdesc is a one line description of the package. This is the sdesc: "boffo: A whackamole simulation in ASCII art" sdesc: "A whackamole simulation in ASCII art" sdesc:"A whackamole simulation in ASCII art" sdesc: "A whackamole simulation in ASCII art" sdesc: "Runtime library for a whackamole simulation in ASCII art" They all seem to have quotes to me. cgf
Re: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
On Thu, May 30, 2002 at 02:09:39PM -0400, Christopher Faylor wrote: > What specific example are you looking at? setup-timestamp: 967844652 @ cygwin sdesc: Cygwin Runtime ldesc: A Posix runtime emulator for Windows platforms version: 1.1.4 [...] at the bottom of http://sources.redhat.com/cygwin-apps/setup.html (which is a different page from http://cygwin.com/setup.html) John
Re: binutils status?
Any comments here? Should I submit this patch to binutils, or can we
agree and commit from here?
--Chuck
Charles Wilson wrote:
> Danny Smith wrote:
>
> >>> I think we should keep the warnings if --auto-import isn't specified
> >>> on the command line but get rid of them if it is explictly
> >>> specified. Including --auto-import on the command line would
> >>> indicate that the user knows what they're doing, so they don't
> >>> need to see warnings.
> >>>
> >> Works for me.
> >>
> >>
> > Agree This addresses my main concern of no warnings and is similar
> > to the way --enable-stdcall-fixup works now.
>
>
> How about this?
>
> Since the tests in /bfd/ are against pei386_auto_import != 0, effectively:
>
> ./bfd/cofflink.c: if (!h && info->pei386_auto_import)
> ./bfd/linker.c: if (info->pei386_auto_import)
>
> We can use the same
> -1 == default, 1 == explicitly enabled, 0 == explicitly disabled
> formuation that stdcall_fixup uses.
>
> I also downgraded the message to 'info_msg' on stdout, instead of
> 'einfo' on stderr (this may be overkill given the 0/1/-1 changes)
>
> Finally, I'm not sure if link_info.pei386_auto_import should be set to
> '0' or to '-1' in ldmain.c. It is *reset* to '-1' at the beginning of
>
> gld_${EMULATION_NAME}_before_parse()
>
> in pe.em...The question is, since pei386_auto_import is part of the
> global link_info structure, should a Solaris linker have that variable
> set to '0' or to '-1'?
>
> I don't think it makes any functional difference, but I'm unsure of the
> stylistic issues.
>
> --Chuck
>
>
>
>
> ? bfd/doc/bfdint.info
> ? bfd/doc/bfdint.info-1
> ? bfd/doc/bfdint.info-2
> ? bfd/doc/bfdsumm.info
> ? ld/ldint.info
> Index: ld/ldmain.c
> ===
> RCS file: /cvs/src/src/ld/ldmain.c,v
> retrieving revision 1.46
> diff -u -r1.46 ldmain.c
> --- ld/ldmain.c 10 May 2002 09:49:25 - 1.46
> +++ ld/ldmain.c 21 May 2002 03:52:12 -
> @@ -258,7 +258,7 @@
>link_info.eh_frame_hdr = false;
>link_info.flags = (bfd_vma) 0;
>link_info.flags_1 = (bfd_vma) 0;
> - link_info.pei386_auto_import = false;
> + link_info.pei386_auto_import = -1; /* 0=disable 1=enable */
>link_info.combreloc = true;
>link_info.spare_dynamic_tags = 5;
>
> Index: ld/emultempl/pe.em
> ===
> RCS file: /cvs/src/src/ld/emultempl/pe.em,v
> retrieving revision 1.59
> diff -u -r1.59 pe.em
> --- ld/emultempl/pe.em15 Feb 2002 02:11:05 - 1.59
> +++ ld/emultempl/pe.em21 May 2002 03:52:18 -
> @@ -173,7 +173,7 @@
> #ifdef DLL_SUPPORT
>config.dynamic_link = true;
>config.has_shared = 1;
> -/* link_info.pei386_auto_import = true; */
> + link_info.pei386_auto_import = -1; /* 1=enable 0=disable */
>
> #if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
> #if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
> @@ -622,10 +622,10 @@
>pe_dll_do_default_excludes = 0;
>break;
> case OPTION_DLL_ENABLE_AUTO_IMPORT:
> - link_info.pei386_auto_import = true;
> + link_info.pei386_auto_import = 1;
>break;
> case OPTION_DLL_DISABLE_AUTO_IMPORT:
> - link_info.pei386_auto_import = false;
> + link_info.pei386_auto_import = 0;
>break;
> case OPTION_ENABLE_EXTRA_PE_DEBUG:
>pe_dll_extra_pe_debug = 1;
> @@ -906,7 +906,10 @@
>sym = bfd_link_hash_lookup (link_info.hash, buf, 0, 0, 1);
>if (sym && sym->type == bfd_link_hash_defined)
> {
> - einfo (_("Warning: resolving %s by linking to %s (auto-import)\n"),
> + if (link_info.pei386_auto_import == -1)
> + {
> +info_msg (_("Info: resolving %s by linking to %s (auto-import)\n"),
> + }
> undef->root.string, buf);
>{
> bfd *b = sym->u.def.section->owner;
Re: binutils status?
On Thu, May 30, 2002 at 03:24:47PM -0400, Charles Wilson wrote: >Any comments here? Should I submit this patch to binutils, or can we >agree and commit from here? Submit it to binutils, please. cgf
[PATCH] pei386: make --enable-auto-import default
auto-import has been turned on by default in the cygwin build since
November, with no ill effects. This patch turns it on by default in
general, but also changes the way auto-import-related
warning/informational messages are issued, depending on whether
auto-import is on by default, or is explicitly enabled (obviously there
are no auto-import-related messages when auto-import is explicitly
disabled...)
Since the tests in /bfd/ against pei386_auto_import are already against
"zero/non-zero", then we can use the same -1 == default (implicitly
enabled), 1 == explicitly enabled, 0 == explicitly disabled formuation
that stdcall_fixup uses.
./bfd/cofflink.c: if (!h && info->pei386_auto_import)
./bfd/linker.c: if (info->pei386_auto_import)
When info->pei386_auto_import = -1 (default) then we continue to issue a
message when auto-importing a variable. If info->pei386_auto_import =
1, then we suppress those informational messages -- the user obviously
knows that she is auto-importing variables, since she explicitly
--enabled them.
I downgraded the "Warning: resolving %s by linking to %s (auto-import)"
message to 'info_msg' on stdout, instead of 'einfo' on stderr.
--Chuck
2002-05-30 Charles Wilson <[EMAIL PROTECTED]>
* ld/ldmain.c (main): initialize link_info.pei386_auto_import
to -1 == implicit enable.
* ld/emultempl/pe.em (gld_${EMULATION_NAME}_before_parse):
initialize link_info.pei386_auto_import to -1 == implicit
enable.
(gld_${EMULATION_NAME}_parse_args): When processing
--enable-auto-import and --disable-auto-import options, use
'1' and '0' instead of 'true' and 'false'.
(pe_find_data_imports): Only issue message about auto-import
when the feature is implicitly enabled. Downgrade message to
informational instead of warning.
? bfd/doc/bfdint.info
? bfd/doc/bfdint.info-1
? bfd/doc/bfdint.info-2
? bfd/doc/bfdsumm.info
? ld/ldint.info
Index: ld/ldmain.c
===
RCS file: /cvs/src/src/ld/ldmain.c,v
retrieving revision 1.46
diff -u -r1.46 ldmain.c
--- ld/ldmain.c 10 May 2002 09:49:25 - 1.46
+++ ld/ldmain.c 21 May 2002 03:52:12 -
@@ -258,7 +258,7 @@
link_info.eh_frame_hdr = false;
link_info.flags = (bfd_vma) 0;
link_info.flags_1 = (bfd_vma) 0;
- link_info.pei386_auto_import = false;
+ link_info.pei386_auto_import = -1; /* 0=disable 1=enable */
link_info.combreloc = true;
link_info.spare_dynamic_tags = 5;
Index: ld/emultempl/pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.59
diff -u -r1.59 pe.em
--- ld/emultempl/pe.em 15 Feb 2002 02:11:05 - 1.59
+++ ld/emultempl/pe.em 21 May 2002 03:52:18 -
@@ -173,7 +173,7 @@
#ifdef DLL_SUPPORT
config.dynamic_link = true;
config.has_shared = 1;
-/* link_info.pei386_auto_import = true; */
+ link_info.pei386_auto_import = -1; /* 1=enable 0=disable */
#if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
#if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
@@ -622,10 +622,10 @@
pe_dll_do_default_excludes = 0;
break;
case OPTION_DLL_ENABLE_AUTO_IMPORT:
- link_info.pei386_auto_import = true;
+ link_info.pei386_auto_import = 1;
break;
case OPTION_DLL_DISABLE_AUTO_IMPORT:
- link_info.pei386_auto_import = false;
+ link_info.pei386_auto_import = 0;
break;
case OPTION_ENABLE_EXTRA_PE_DEBUG:
pe_dll_extra_pe_debug = 1;
@@ -906,7 +906,10 @@
sym = bfd_link_hash_lookup (link_info.hash, buf, 0, 0, 1);
if (sym && sym->type == bfd_link_hash_defined)
{
- einfo (_("Warning: resolving %s by linking to %s (auto-import)\n"),
+ if (link_info.pei386_auto_import == -1)
+ {
+info_msg (_("Info: resolving %s by linking to %s (auto-import)\n"),
+ }
undef->root.string, buf);
{
bfd *b = sym->u.def.section->owner;
Re: binutils status?
Christopher Faylor wrote: > On Thu, May 30, 2002 at 03:24:47PM -0400, Charles Wilson wrote: > >>Any comments here? Should I submit this patch to binutils, or can we >>agree and commit from here? > > > Submit it to binutils, please. done. --Chuck
Re: Excude whole libs when building w32 dlls with -export-all [Refresh]
FWIW, it appears that this patch was committed on 21 May 2002.
--Chuck
Danny Smith wrote:
> The previous post had incorrect subject heading. This is a repost. Sorry.
>
> This is a refresh of:
>
> http://sources.redhat.com/ml/binutils/2002-04/msg00472.html
>
> The patch allows exclusion of symbols in specified libs (optionally all
> libs) from export table when producing dll's using ld --shared.
> Listing of symbol names in a .def file forces those specific symbols
> to be included even if they are contained in excluded libs.
>
>
>
> Can this be reviewed?
>
> The diff updated to current CVS is attached.
>
> 2002-05-21 Danny Smith <[EMAIL PROTECTED]>
>
> * emultempl/pe.em (OPTION_EXCLUDE_LIBS): Add new define.
> (longopts): Add new option --exclude-libs.
> (gld_${EMULATION_NAME}_list_options): Give quick help about it.
> (gld_${EMULATION_NAME}_parse_args): Use it.
> * pe-dll.h (pe_dll_add_excludes): Add second param to prototype.
> * pe-dll.c (exclude_list_struct): Add field type to distinguish
> symbols from whole archives.
> (pe_dll_add_excludes): Set excludes->type.
> (auto_export): Add new variable libname and set to
> archive basename if abfd. Use it when filtering default and
> user-specified libarary excludes. Let string "ALL" mean all libs
> when filtering user-specified libs.
> * ld.texinfo: Document --exclude-libs.
RE: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
Ton wrote: > > One thing Carl could try is to use the latest setup snapshot on > http://cygwin.com/setup-snapshots/. > The latest one right now is setup-2.249.exe. > See if the problem is still there on XP with that version. > I followed this advice The result: An error window titled "Cygwin Setup" gives the message "Unable to get setup.ini from http://prc-tools.sourceforge.net/install";. I pointed my browser at http://prc-tools.sourceforge.net/install/setup.ini and successfully downloaded a copy of the setup.ini file. Two questions: (1) is there a way to make setup.exe use the setup.ini from my drive, rather than getting a copy from the prc-tools site? (2) Is there something different about the way setup processes http:// mirror sites instead of ftp:// mirror sites? Carl
Re: [PATCH] pei386: make --enable-auto-import default
Blarg. The dangers of "one last change" without actually testing it.
Use the attached patch instead of earlier one...
this one actually compiles, works, and does what the changelog claims.
Sorry for the confusion.
--Chuck
Charles Wilson wrote:
> auto-import has been turned on by default in the cygwin build since
> November, with no ill effects. This patch turns it on by default in
> general, but also changes the way auto-import-related
> warning/informational messages are issued, depending on whether
> auto-import is on by default, or is explicitly enabled (obviously there
> are no auto-import-related messages when auto-import is explicitly
> disabled...)
>
> Since the tests in /bfd/ against pei386_auto_import are already against
> "zero/non-zero", then we can use the same -1 == default (implicitly
> enabled), 1 == explicitly enabled, 0 == explicitly disabled formuation
> that stdcall_fixup uses.
>
> ./bfd/cofflink.c: if (!h && info->pei386_auto_import)
> ./bfd/linker.c: if (info->pei386_auto_import)
>
> When info->pei386_auto_import = -1 (default) then we continue to issue a
> message when auto-importing a variable. If info->pei386_auto_import =
> 1, then we suppress those informational messages -- the user obviously
> knows that she is auto-importing variables, since she explicitly
> --enabled them.
>
> I downgraded the "Warning: resolving %s by linking to %s (auto-import)"
> message to 'info_msg' on stdout, instead of 'einfo' on stderr.
>
> --Chuck
>
> 2002-05-30 Charles Wilson <[EMAIL PROTECTED]>
>
> * ld/ldmain.c (main): initialize link_info.pei386_auto_import
> to -1 == implicit enable.
> * ld/emultempl/pe.em (gld_${EMULATION_NAME}_before_parse):
> initialize link_info.pei386_auto_import to -1 == implicit
> enable.
> (gld_${EMULATION_NAME}_parse_args): When processing
> --enable-auto-import and --disable-auto-import options, use
> '1' and '0' instead of 'true' and 'false'.
> (pe_find_data_imports): Only issue message about auto-import
> when the feature is implicitly enabled. Downgrade message to
> informational instead of warning.
Index: ld/ldmain.c
===
RCS file: /cvs/src/src/ld/ldmain.c,v
retrieving revision 1.47
diff -u -r1.47 ldmain.c
--- ld/ldmain.c 22 May 2002 05:08:30 - 1.47
+++ ld/ldmain.c 30 May 2002 23:13:01 -
@@ -259,7 +259,7 @@
link_info.eh_frame_hdr = false;
link_info.flags = (bfd_vma) 0;
link_info.flags_1 = (bfd_vma) 0;
- link_info.pei386_auto_import = false;
+ link_info.pei386_auto_import = -1; /* 0=disable 1=enable */
link_info.combreloc = true;
link_info.spare_dynamic_tags = 5;
Index: ld/emultempl/pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.63
diff -u -r1.63 pe.em
--- ld/emultempl/pe.em 27 May 2002 08:22:08 - 1.63
+++ ld/emultempl/pe.em 30 May 2002 23:13:05 -
@@ -173,7 +173,7 @@
#ifdef DLL_SUPPORT
config.dynamic_link = true;
config.has_shared = 1;
-/* link_info.pei386_auto_import = true; */
+ link_info.pei386_auto_import = -1; /* 1=enable 0=disable */
#if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
#if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
@@ -628,10 +628,10 @@
pe_dll_do_default_excludes = 0;
break;
case OPTION_DLL_ENABLE_AUTO_IMPORT:
- link_info.pei386_auto_import = true;
+ link_info.pei386_auto_import = 1;
break;
case OPTION_DLL_DISABLE_AUTO_IMPORT:
- link_info.pei386_auto_import = false;
+ link_info.pei386_auto_import = 0;
break;
case OPTION_ENABLE_EXTRA_PE_DEBUG:
pe_dll_extra_pe_debug = 1;
@@ -912,8 +912,11 @@
sym = bfd_link_hash_lookup (link_info.hash, buf, 0, 0, 1);
if (sym && sym->type == bfd_link_hash_defined)
{
- einfo (_("Warning: resolving %s by linking to %s (auto-import)\n"),
+ if (link_info.pei386_auto_import == -1)
+ {
+info_msg (_("Info: resolving %s by linking to %s (auto-import)\n"),
undef->root.string, buf);
+ }
{
bfd *b = sym->u.def.section->owner;
asymbol **symbols;
RE: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
You need a trailing / on the custom URL. Rob > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Carl Sorensen > Sent: Friday, 31 May 2002 9:00 AM > To: 'Ton van Overbeek'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Setup 2.218.2.9 fails to read setup.ini file > from prc-tools mirror > > > Ton wrote: > > > > > > One thing Carl could try is to use the latest setup snapshot on > > http://cygwin.com/setup-snapshots/. > > The latest one right now is setup-2.249.exe. > > See if the problem is still there on XP with that version. > > > > I followed this advice > > The result: > > An error window titled "Cygwin Setup" gives the message > "Unable to get setup.ini from > http://prc-tools.sourceforge.net/install";. > > I pointed my > browser at http://prc-tools.sourceforge.net/install/setup.ini > and successfully downloaded a copy of the setup.ini file. > > Two questions: > (1) is there a way to make setup.exe use the setup.ini from > my drive, rather than getting a copy from the prc-tools site? > > (2) Is there something different about the way setup > processes http:// mirror sites instead of ftp:// mirror sites? > > Carl > >
RE: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
Thanks, I've corrected this. Rob > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of John Marshall > Sent: Friday, 31 May 2002 4:18 AM > To: [EMAIL PROTECTED] > Subject: Re: Setup 2.218.2.9 fails to read setup.ini file > from prc-tools mirror > > > On Thu, May 30, 2002 at 02:09:39PM -0400, Christopher Faylor wrote: > > What specific example are you looking at? > > setup-timestamp: 967844652 > > @ cygwin > sdesc: Cygwin Runtime > ldesc: A Posix runtime emulator for Windows platforms > version: 1.1.4 > [...] > > at the bottom of http://sources.redhat.com/cygwin-apps/setup.html > (which is a different page from http://cygwin.com/setup.html) > > John >
RE: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
Rob, I entered the trailing / when I added the custom URL. However, when the error window popped up, it did not have the trailing /. More information: When running Setup.exe 2.218.2.9, if I select the option "Use IE5 Settings", I get the "Unable to get setup.ini message", rather than the "Parse error" message. On Thursday, May 30, 2002 5:28 PM, Robert Collins [SMTP:[EMAIL PROTECTED]] wrote: > You need a trailing / on the custom URL. > > Rob > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Carl Sorensen > > Sent: Friday, 31 May 2002 9:00 AM > > To: 'Ton van Overbeek'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: Setup 2.218.2.9 fails to read setup.ini file > > from prc-tools mirror > > > > > > Ton wrote: > > > > > > > > > > One thing Carl could try is to use the latest setup snapshot on > > > http://cygwin.com/setup-snapshots/. > > > The latest one right now is setup-2.249.exe. > > > See if the problem is still there on XP with that version. > > > > > > > I followed this advice > > > > The result: > > > > An error window titled "Cygwin Setup" gives the message > > "Unable to get setup.ini from > > http://prc-tools.sourceforge.net/install";. > > > > I pointed my > > browser at http://prc-tools.sourceforge.net/install/setup.ini > > and successfully downloaded a copy of the setup.ini file. > > > > Two questions: > > (1) is there a way to make setup.exe use the setup.ini from > > my drive, rather than getting a copy from the prc-tools site? > > > > (2) Is there something different about the way setup > > processes http:// mirror sites instead of ftp:// mirror sites? > > > > Carl > > > >
RE: Setup 2.218.2.9 fails to read setup.ini file from prc-tools mirror
Hmm, strange. I just tried this myself, and got the same result (I used direct connection, rather than IE settings). Yet, wget gets the file fine. Hmm, ah yes. DON'T put the last '/' in. Works fine for me now. Rob > -Original Message- > From: Carl Sorensen [mailto:[EMAIL PROTECTED]] > Sent: Friday, 31 May 2002 9:57 AM > To: 'Robert Collins' > Subject: RE: Setup 2.218.2.9 fails to read setup.ini file > from prc-tools mirror > > > Rob, > > I entered the trailing / when I added the custom URL. > However, when the > error window popped up, it did not have the trailing /. > > More information: When running Setup.exe 2.218.2.9, if I > select the option > "Use IE5 Settings", I get the "Unable to get setup.ini > message", rather > than the "Parse error" message. > > > On Thursday, May 30, 2002 5:28 PM, Robert Collins > [SMTP:[EMAIL PROTECTED]] wrote: > > You need a trailing / on the custom URL. > > > > Rob > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Carl Sorensen > > > Sent: Friday, 31 May 2002 9:00 AM > > > To: 'Ton van Overbeek'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Subject: RE: Setup 2.218.2.9 fails to read setup.ini file > > > from prc-tools mirror > > > > > > > > > Ton wrote: > > > > > > > > > > > > > > One thing Carl could try is to use the latest setup snapshot on > > > > http://cygwin.com/setup-snapshots/. > > > > The latest one right now is setup-2.249.exe. > > > > See if the problem is still there on XP with that version. > > > > > > > > > > I followed this advice > > > > > > The result: > > > > > > An error window titled "Cygwin Setup" gives the message > > > "Unable to get setup.ini from > > > http://prc-tools.sourceforge.net/install";. > > > > > > I pointed my > > > browser at http://prc-tools.sourceforge.net/install/setup.ini > > > and successfully downloaded a copy of the setup.ini file. > > > > > > Two questions: > > > (1) is there a way to make setup.exe use the setup.ini from > > > my drive, rather than getting a copy from the prc-tools site? > > > > > > (2) Is there something different about the way setup > > > processes http:// mirror sites instead of ftp:// mirror sites? > > > > > > Carl > > > > > > > >
RE: [PATCH] pei386: make --enable-auto-import default
> > When info->pei386_auto_import = -1 (default) then we continue to issue a > message when auto-importing a variable. If info->pei386_auto_import = > 1, then we suppress those informational messages -- the user obviously > knows that she is auto-importing variables, since she explicitly > --enabled them. That means, adding --enable-auto-import to the command will only suppress the warning, isnt' it ? Ralf
Re: [PATCH] pei386: make --enable-auto-import default
Ralf Habacker wrote: >>When info->pei386_auto_import = -1 (default) then we continue to issue a >>message when auto-importing a variable. If info->pei386_auto_import = >>1, then we suppress those informational messages -- the user obviously >>knows that she is auto-importing variables, since she explicitly >>--enabled them. >> > > That means, adding --enable-auto-import to the command will only suppress the > warning, isnt' it ? Correct. Current official binutils behavior: --disable-auto-import is the default. --enable-auto-import turns on the feature, but will print warnings whenever the feature is used. Current cygwin bintuils behavior: --enable-auto-import is the default, so the feature is usually active. However, it prints warnings whenever the feature is used. --disable-auto-import...turns of the feature With my patch: default behavior: ALMOST the same as current cygwin binutils behavior. auto-import feature is active, but an informational message (NOT a warning) is printed whenever the feature is used. --enable-auto-import: don't print the informational message/warning. --disable-auto-import: turn the feature off... --Chuck
