Re: [ITP] ccache
Hallo Christopher, Am Sonntag, 19. Mai 2002 um 04:40 schriebst du: Out of curiousity, has anyone tried this: http://ccache.samba.org/ on cygwin? It seems to provides an amazing speedup for compilations. It builds OOTB. On linux, this makes my cygwin builds so fast, that it almost seems like I could get rid of dependency checking and just always rebuild everything. Well, a little late for a comment, but I want to state the following: I wonder that I didn't hear about this 'program' before today. I once was so angry because reconfiguring takes everytime so long and does always the same that I intended to to such kind of package myself, it seems this isn't no longer needed and I will use it as much as possible if it works out to be useful. I will install it immediatly if it is already up on the mirrors. Gerrit -- =^..^= --
Packaging error with latest texinfo-4.2-2.tar ??
Hi The directory /usr/info is empty in the texinfo-4.2-2.tar archive. At least in the texinfo-4.1-1.tar file it was populated with: -- TAR:texinfo-4.1-1.tar\usr\info info.info¦ 5425 info-stnd.info ¦263 info-stnd.info-1 ¦ 5049 info-stnd.info-2 ¦ 4224 texinfo ¦ 1055 texinfo-1¦ 4897 texinfo-10 ¦ 4508 texinfo-11 ¦ 5073 texinfo-12 ¦ 5019 texinfo-13 ¦ 4594 texinfo-2¦ 4956 texinfo-3¦ 5080 texinfo-4¦ 4980 texinfo-5¦ 5088 texinfo-6¦ 5058 texinfo-7¦ 5067 texinfo-8¦ 4937 texinfo-9¦ 4914 Ciao Volker
Re: [ITP] ccache
I once was so angry because reconfiguring takes everytime so long and does always the same that I intended to to such kind of package myself, it seems this isn't no longer needed and I will use it as much as possible if it works out to be useful. Same for me, that must me a dream, looking forward to use it =) -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Why is also Misc category installed for a fresh Cygwin install ?
When testing my patch for the Setup source download incomplete problem I noticed that a fresh install pulls in all packages in Base and Misc. Before there were no packages in Misc in setup.ini, but now there is: ccache. (That's how I noticed it, ccache showing up in the chooser list for a fresh install) I know Misc is used when installing from local directory. So, should we not use Misc in setup.ini ? As far as ccache itself is concerned, I believe it should be in Devel and its setup.hint probably needs a requires: gcc line as well. Regards, Ton van Overbeek
Re: [ITP] ccache
It will not save any time in running configure (except for all the test compilations while running configure). I always thought they were 90% of configure's time.. am I wrong? -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
RE: Why is also Misc category installed for a fresh Cygwin install ?
As you say, ccache should be a devel package, not misc. I missed that in Chris's setup.hint. Chris - any objection to switching ccache to Devel? As for requires, it cacn cache any compiler, so it doesn't require gcc. Misc is always installed, as is base. When you have a local package dir with no setup.ini, unknown packages go into misc and install be default. This is by design. Rob -Original Message- From: Ton van Overbeek [mailto:[EMAIL PROTECTED]] Sent: Monday, May 20, 2002 3:43 AM To: [EMAIL PROTECTED] Subject: Why is also Misc category installed for a fresh Cygwin install ? When testing my patch for the Setup source download incomplete problem I noticed that a fresh install pulls in all packages in Base and Misc. Before there were no packages in Misc in setup.ini, but now there is: ccache. (That's how I noticed it, ccache showing up in the chooser list for a fresh install) I know Misc is used when installing from local directory. So, should we not use Misc in setup.ini ? As far as ccache itself is concerned, I believe it should be in Devel and its setup.hint probably needs a requires: gcc line as well. Regards, Ton van Overbeek
RE: [PATCH] Setup.exe 2.218.2.9 does not like its own source
-Original Message-
From: Ton van Overbeek [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 20, 2002 3:26 AM
The attached patch makes setup download the source of setup
without complaining.
I am not totally at home with all the logic in
package_meta.cc and its interaction with the chooser to know
if this change causes other problems. So I will not be
surprised if this is not the 'right' solution.
It's not, it alters the default install logic, so you'll be getting the
wrong version by default when you select install at a category level or
click on a pacakage. ('If (installed)' means that packages won't install
on the first click, which is wrong.)
The correct test is:
(desired-bin.sites.number() || desired-bin.Cached())
i.e. if there are download sites that the desired package can come from
or it's known to be cached then we should turn bin on. This also catches
another bug, where reinstall was a valid choice for a installed package
on a local install, regardless of package availability. Thank you for
tracking down the specific location though - that saved me quite some
time.
The fix I'll be committing is below. It makes a source only package
install the source by default in addition to the bug fix above. I also
noticed another minor bug when iterating through lots of packges
locally.
Rob
Index: package_meta.cc
===
RCS file: /cvs/cygwin-apps/setup/package_meta.cc,v
retrieving revision 2.22
diff -u -p -r2.22 package_meta.cc
--- package_meta.cc 4 May 2002 04:26:01 - 2.22
+++ package_meta.cc 20 May 2002 01:04:40 -
@@ -318,8 +318,14 @@ packagemeta::set_action (packageversion
}
return;
}
- else if (desired == installed
- (!installed || !(installed-binpicked ||
installed-srcpicked)))
+ else if (desired == installed
+ (!installed ||
+ // neither bin nor source are being installed
+ (!(installed-binpicked || installed-srcpicked)
+// bin or source are available
+((installed-bin.sites.number() || desired-bin.Cached())
||
+ (installed-src.sites.number() ||
desired-src.Cached()
+ )
/* Install the default trust version - this is a 'reinstall' for
installed
* packages */
{
@@ -328,7 +334,10 @@ packagemeta::set_action (packageversion
desired = default_version;
if (desired)
{
- desired-binpicked = 1;
+ if (desired-bin.sites.number() || desired-bin.Cached())
+ desired-binpicked = 1;
+ else
+ desired-srcpicked = 1;
return;
}
}
@@ -375,7 +384,10 @@ packagemeta::set_action (packageversion
if (n = versions.number ())
{
desired = versions[n];
- desired-srcpicked = source;
+ if (desired-src.sites.number() || desired-src.Cached())
+ desired-srcpicked = source;
+ else
+ desired-srcpicked = 0;
return;
}
}
Re: Packaging error with latest texinfo-4.2-2.tar ??
On Sun, May 19, 2002 at 05:16:16PM +0200, Dr. Volker Zell wrote: The directory /usr/info is empty in the texinfo-4.2-2.tar archive. Thanks for the notification. This should be corrected in texinfo-4.2-3. There were also some other files missing. This was YA case of a package not liking the fact that the build/src directories were different. cgf
Re: Packaging error with findutils-4.1.7-3
Christopher Faylor wrote: On Sun, May 19, 2002 at 02:51:22PM +0200, Dr. Volker Zell wrote: See subject. findutils-4.1.7-3 installs .mo files under /lib/locale/ instead of /usr/share/locale/ Thanks for the heads up. Should be fixed. Enabling --auto-import for ld solved this problem. Huh? Wha...? How does enabling '--auto-import' for ld solve a problem with the installation location of language translation tables? Second, why do you have to specify --auto-import for anything? '--enable-auto-import' IS the default... I'm sooo confused --Chuck
Re: binutils status?
Christopher Faylor wrote: I lost track. Should I make a new release or are we waiting for something new to be added? I just rebuilt binutils and made --auto-import the default. Is there a compelling reason for not doing this in the next release? I know that --auto-import isn't perfect but will it solve more problems than it creates? Waitaminute. I thought it already was the default. Hmmm...let me go check...weird, I don't see --enable-auto-import in any of my makefiles, yet I know that I'm linking to _nm_ symbols... Hmm...have I been using a local build of ld.exe all this time? Nope, datestamp on the file is 20011002... Color me confused. But if it ain't the default, it should be. And we should probably remove the warning message that gets printed (around line 908 in pe.em), or downgrade it so that it only gets printed when -v (verbose). Other than that, I know of three different things we're still waiting on (or maybe they've been committed and I missed it): 1) Ralf's removing unused _nm_ symbol exports fix 2) Danny's (or Ralf's?) export-list fix (where whole static archives can be marked for non-export, or DO export...helpful for convenience libs) 3) Ralf's patch for objdump/cygwin crashes on auto-imported libs --Chuck
Re: Packaging error with findutils-4.1.7-3
On Mon, May 20, 2002 at 12:37:58AM -0400, Charles Wilson wrote:
Christopher Faylor wrote:
On Sun, May 19, 2002 at 02:51:22PM +0200, Dr. Volker Zell wrote:
See subject.
findutils-4.1.7-3 installs .mo files under /lib/locale/
instead of /usr/share/locale/
Thanks for the heads up. Should be fixed.
Enabling --auto-import for ld solved this problem.
Huh? Wha...?
How does enabling '--auto-import' for ld solve a problem with the
installation location of language translation tables?
Can't you imagine all sorts of scenarios where a configure script, which
assumes normal unix linking of external symbols, becoming confused if
--auto-import wasn't on.
Second, why do you have to specify --auto-import for anything?
'--enable-auto-import' IS the default...
I applied the following patch to the sources:
Index: emultempl/pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.59
diff -u -p -r1.59 pe.em
--- emultempl/pe.em 15 Feb 2002 02:11:05 - 1.59
+++ emultempl/pe.em 20 May 2002 04:51:53 -
-173,7 +173,7 gld_${EMULATION_NAME}_before_parse()
#ifdef DLL_SUPPORT
config.dynamic_link = true;
config.has_shared = 1;
-/* link_info.pei386_auto_import = true; */
+ link_info.pei386_auto_import = true;
#if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
#if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
Trying this on Windows, I can see that it is on by default there. I
guess this must have gotten wiped out in my sandbox when I rebuilt
binutils for linux. Don't know how that happened.
So, nevermind about the question about turning it on by default.
The real question is whether this should be on in CVS. Obviously
it should be.
cgf
Re: binutils status?
On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote: 1) Ralf's removing unused _nm_ symbol exports fix 2) Danny's (or Ralf's?) export-list fix (where whole static archives can be marked for non-export, or DO export...helpful for convenience libs) 3) Ralf's patch for objdump/cygwin crashes on auto-imported libs If Ralf and Danny will resubmit their patches against the current CVS, I will at least incorporate them in a new version of binutils, even if I don't check them in. I'd say go ahead and turn on auto-import in CVS and remove the warning, Chuck. I've gotten approval from Nick Clifton to do this if we agree it's a good idea. It's obviously a good idea. cgf
Re: Packaging error with findutils-4.1.7-3
Christopher Faylor wrote: Can't you imagine all sorts of scenarios where a configure script, which assumes normal unix linking of external symbols, becoming confused if --auto-import wasn't on. Of course. must get more sleep. Second, why do you have to specify --auto-import for anything? '--enable-auto-import' IS the default... I applied the following patch to the sources: Oops. My *binary* ld.exe is your official release. However, my local copy of the SOURCES had already been modified at some time in the distant past, with the patch you described. Sheesh. Trying this on Windows, I can see that it is on by default there. I guess this must have gotten wiped out in my sandbox when I rebuilt binutils for linux. Don't know how that happened. So, nevermind about the question about turning it on by default. The real question is whether this should be on in CVS. Obviously it should be. Yes. --Chuck
Re: Packaging error with findutils-4.1.7-3
On Mon, May 20, 2002 at 01:30:00AM -0400, Charles Wilson wrote: I applied the following patch to the sources: Oops. My *binary* ld.exe is your official release. However, my local copy of the SOURCES had already been modified at some time in the distant past, with the patch you described. Sheesh. Obviously mine must have been too. It wasn't you who was confused, here. It was me. cgf
Re: binutils status?
Christopher Faylor wrote:
On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote:
1) Ralf's removing unused _nm_ symbol exports fix
2) Danny's (or Ralf's?) export-list fix (where whole static archives can
be marked for non-export, or DO export...helpful for convenience libs)
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs
If Ralf and Danny will resubmit their patches against the current CVS,
I will at least incorporate them in a new version of binutils, even
if I don't check them in.
Very good. Ralf? Danny?
I'd say go ahead and turn on auto-import in CVS and remove the warning,
Chuck. I've gotten approval from Nick Clifton to do this if we agree
it's a good idea.
It's obviously a good idea.
Attached.
--chuck
Index: pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.59
diff -u -r1.59 pe.em
--- pe.em 15 Feb 2002 02:11:05 - 1.59
+++ pe.em 20 May 2002 05:26:50 -
-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 = true;
#if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
#if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
-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 (pe_dll_extra_pe_debug)
+ {
+einfo (_(Warning: resolving %s by linking to %s (auto-import)\n),
+ }
undef-root.string, buf);
{
bfd *b = sym-u.def.section-owner;
