RE: ITP: netpbm
> > > > > -Original Message- > > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 27, 2002 6:03 AM > > > As for the # of executables in the /bin directory, isn't > > there a limit to the number of files and/or directory entries > > in any one directory on win32? > >As has already been said, not past the root. However directory search >time is O(N) on FAT, vs (IIRC) O(logN) on NTFS. So directories with many >files leads to signficcantly longer lookup times - and thas when the >filename is known!. My experience - on ntfs ... i have a directory of approx 10thousand 5 minute log files of me playing telnet based muds ... *snicker* i can grep them all (each about 10-20k) in a few minutes ... (9 grep commands because command line expansion limitations :P) - really preformance drop is not that noticible. Except in one area. cd'ing to the directory in the first place - can take a minute or more, subsequent cd's are fast, but it seems like its caching all the filenames in the directory for faster access. Anyway ... theres a 'pseudo-data-point' Regards, Gareth _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
RE: [teilo@cdt.luth.se: Re: [bug?] binary mount point option in setup]
> -Original Message-
> From: Christopher Faylor [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 6:17 AM
> To: [EMAIL PROTECTED]
> Subject: [[EMAIL PROTECTED]: Re: [bug?] binary mount point
> option in setup]
>
>
> It isn't a proper patch, but maybe this should be
> incorporated into setup, if it isn't already.
>
> It seems like a valid problem.
It is, but the solution was wrong.
Index: mount.cc
===
RCS file: /cvs/cygwin-apps/setup/mount.cc,v
retrieving revision 2.12
diff -u -p -r2.12 mount.cc
--- mount.cc26 Apr 2002 08:10:32 - 2.12
+++ mount.cc27 Apr 2002 01:37:08 -
@@ -238,6 +238,11 @@ set_cygdrive_flags (int istext, int issy
{
DWORD cygdrive_flags = 0;
status = get_cygdrive_flags (key, &cygdrive_flags);
+ if (status == ERROR_FILE_NOT_FOUND)
+ {
+ status = ERROR_SUCCESS;
+ cygdrive_flags = default_cygdrive (key);
+ }
if (status == ERROR_SUCCESS)
{
set_cygdrive_flags (key, istext, cygdrive_flags);
This is a more correct solution. I'm uploading a new setup snapshot to
http://www.cygwin.com/setup-snapshots, if anone would like to test this
out.
Rob
RE: attn cgf - single build integration
> -Original Message- > From: Robert Collins > Sent: Saturday, April 20, 2002 9:50 AM > To: Cygwin-Apps > Subject: attn cgf - single build integration > > > Chris, > I'm approaching a point with libgetopt++ that I'll want > to roll it into setup. This will (obviously) affect the > single-build procress, so I'm hoping that you can confirm or > suggest alterations to my plan: > > I think that as a general purpose library, it should sit at > winsup/libgetopt++ or even a level above. However the binary > linked into setup.exe needs to be built knowing about setup's > String class (as opposed to the C++ standard basic_string). > > So here's my idea: > we put the library at winsup/libgetopt++ > we make a symlink in the source tree at cinstall/libgetopt++ > to ../libgetopt++ > > During configure time setup sub-configures libgetopt++ as a > static only library in cinstall/libgetopt++ > > In the future if any other programs want to start using it, > we make winsup subconfigure winsup/libgetopt++. > > What do you think? With setup moved, there is no current requirement to put libgetopt++ in the winsup tree, so I won't be doing the above. Of course, it's such a great library it should be there :}. Rob
Re: updating local CVS to new location of setup
On Sat, Apr 27, 2002 at 11:04:43AM +1000, Robert Collins wrote: >This is just a hint, for anyone caught short by the rapid >decision-to-move and actual move. > >If you edit cinstall/CVS/Root and change >...:/cvs/src >to >...:/cvs/cygwin-apps >and edit cinstall/CVS/Repository and change >src/winsup/cinstall >to >setup > >then you will be able to carry on doing cvs updates and cvs diff with no >interruption to your work. Over in winsup land, You may also have to fiddle with winsup/CVS/Entries to make it understand that cinstall is no longer a directory. cgf
updating local CVS to new location of setup
This is just a hint, for anyone caught short by the rapid decision-to-move and actual move. If you edit cinstall/CVS/Root and change ...:/cvs/src to ...:/cvs/cygwin-apps and edit cinstall/CVS/Repository and change src/winsup/cinstall to setup then you will be able to carry on doing cvs updates and cvs diff with no interruption to your work. Rob
RE: ordinal linking for cygwin ld
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 10:55 AM > > > Or ld has a switch to explicit use ordinals (see other mails from > > > me) > > > > I don't see what such a switch gains. The hint ordinal > should provide > > the same performance as an ordinal-only-link. > > By default ld does not use ordinals or linking. Only when an > import lib does not contain names in the _nm_vector, ld takes > the ordinal for linking (identified by flag_noname in > pe-dll.c/ei386pe.c). Thats what I have used. I have patched > ld to write the import library only with ordinals and ld does > the rest. Only an additional patch for auto-imported date was > necessary. (see the patch) Well then, this is only half the puzzle. I can see what you gain from such a patch, but as Chuck as indicated, it will cause -major- difficulties in management. A patch to use hint ordinals when linking by name would be _very_ useful though, as that would a) give the performance benefit you are looking for b) allow backward compatible library versioning as link-by-name does. We'd probably also need to ensure that strip leaves the names in the IAT (I wasn't clear from your other email whether it does that or not). Rob
RE: ordinal linking for cygwin ld
Ralf Habacker > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins > Sent: Saturday, April 27, 2002 2:26 AM > To: Ralf Habacker; Charles Wilson > Cc: Kde-Cygwin; Binutils; Cygwin-Apps > Subject: RE: ordinal linking for cygwin ld > > > > > > -Original Message- > > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 27, 2002 10:23 AM > > To: Robert Collins; Charles Wilson > > Cc: Kde-Cygwin; Binutils; Cygwin-Apps > > Subject: RE: ordinal linking for cygwin ld > > > > > > > The PE spec (as I read it) indicates that as long as a name is > > > included (ie it's not link-only-by-ordinal) then ordinals > > can change > > > and nothing will break. > > > > > > It's only when the only link information is the ordinal > > that problems > > > will appear. > > > > Or ld has a switch to explicit use ordinals (see other mails from me) > > I don't see what such a switch gains. The hint ordinal should provide > the same performance as an ordinal-only-link. By default ld does not use ordinals or linking. Only when an import lib does not contain names in the _nm_vector, ld takes the ordinal for linking (identified by flag_noname in pe-dll.c/ei386pe.c). Thats what I have used. I have patched ld to write the import library only with ordinals and ld does the rest. Only an additional patch for auto-imported date was necessary. (see the patch) Ralf
setup and exceptions
Well, I've just tried, and exceptions do work. The stdc++ library I've got here appears to have been built without thread support, so we can't use cross-thread exceptions. In fact IIRC we can only use exceptions within a single thread. This means that some care is needed before we introduce any exception using code. I'm not sure if gcc needs to be reubuilt if/when threads are enabled... If the answer is yes, then simply getting a threaded libstdc++ is not enough. If the answer is no, and "someone" were to make a prebuilt mingw libstdc++ available with thread support, then we can use exceptions more freely. For the moment, when I get time, I'll review what occurs in each thread, and what mechanism we might use to safely get some benefits. i.e. if the only time we have multiple threads is a separate GUI update thread, then as long as that update thread never creates or absorbs exceptions, we are safe. Rob
RE: ordinal linking for cygwin ld
Ld rules: > 1. By default ordinal linking is disabled > > 2. Add an ld option to enable ordinal linking. >As ordinal the hint number is used. (Could this have any unknown > side effect ??) >ordinal = hint number + 1. >How should such an option be named ? --enable-ordinal-link ? Now, I'm going to bed, it is 2:43am in germany. God night. Ralf
RE: ordinal linking for cygwin ld
> > OTOH, if you've linked by ordinal, and then you strip symbols > > -- are the > > names of the imports still retained? > The symbols are removed, but in the _nm_vector the names are still retained. Ralf
RE: ordinal linking for cygwin ld
> The PE spec (as I read it) indicates that as long as a name is included > (ie it's not link-only-by-ordinal) then ordinals can change and nothing > will break. > > It's only when the only link information is the ordinal that problems > will appear. Or ld has a switch to explicit use ordinals (see other mails from me)
RE: ordinal linking for cygwin ld
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 10:23 AM > To: Robert Collins; Charles Wilson > Cc: Kde-Cygwin; Binutils; Cygwin-Apps > Subject: RE: ordinal linking for cygwin ld > > > > The PE spec (as I read it) indicates that as long as a name is > > included (ie it's not link-only-by-ordinal) then ordinals > can change > > and nothing will break. > > > > It's only when the only link information is the ordinal > that problems > > will appear. > > Or ld has a switch to explicit use ordinals (see other mails from me) I don't see what such a switch gains. The hint ordinal should provide the same performance as an ordinal-only-link. Rob
libgetopt++ and setup and libstdc++
Ok,
we're finally there. Setup now can use libstdc++ routines,
allowing the full range of C++ programming constructs. Probably even
exceptions, but I have not tested that yet.
I've removed the half-done GetOption.cc and GetOption.h from setup, they
are part of libgetopt++, which is a much easier tool for options.
*** IMPORTANT ***
libgetopt++ does not store the autotool created files in CVS. You'll
need to run ./bootstrap.sh in it's source dir to create them.
*
>From a CVS point of view, libgetopt++ is included via a reference to the
libgetopt++ module in cygwin-apps. That means that any changes to
setup/libgetopt++ are reflected immediately in the master libgetopt++
location, and vice versa. Please check with me before checking in change
to libgetopt++.
I've updated the sample option in desktop.cc. It now looks like this:
==
#include "getopt++/BoolOption.h"
static BoolOption NoShortcutsOption (false, 'n',
"no-shortcuts", "Disable creation of desktop and start menu
shortcuts");
==
That's it. Check the value by
if (NoShortcutsOption) or if(!NoShortcutsOption).
There is another helper class, StringOption. It's syntax is very
similar:
i.e.
static StringOption errname("defaultvalue", 'e', "errname", "specify
program name for errors");
and cast it to (string) to get the value.
These are polymorphic constructors. See the source for the extra
options.
Anyway, this should allow trivial addition of options, in an object
orientated approach.
We can also use the C++ string class. However, except for the trivial -
such as option parsing - we should still use the cistring or String++
classes, as we need unicode support eventually, and also formatmessage
support. They can of course use string as an underlying container if
appropriate.
All this comes with a price: a mingw libstdc++ is required to link
against. One is available in the mingw gcc binary, or you can roll your
own. I realise that this does affect cross compilers, in that a 'pure'
i686-pc-cygwin won't have such a library. However I build with
-mno-cygwin very happily, and while I'm the one generating the setup
that goes on sourceware, I really don't think this is an issue.
So what does all this mean? Setup is going to get a smaller code base
over the next month or so. I'll be stripping out a lot of the custom
built duplicates of standard functionality, and leveraging whats 'out
there'. No, I won't be adding any (more) 3rd party build dependencies.
That probably means no use of the STL for now. Ahh well, nothings
perfect :}. After at least one more production release, I will review
with the list the direction we should take setup, and we can consider
adding the STL or other such utility libraries.
Rob
RE: ordinal linking for cygwin ld
> > If *you* release new "compatible" libs with the ordinals different from > the current libs, *my* application breaks. Or, you might get ripple > effects: what if I distribute a dll that depends on KDE's libs, and Bob > has an app that depends on my dll? Bob's app breaks because my dll is > broken because you released new "compatible" libs. Not good -- and it'd > take a while to track the problem down too: (a) I need to relink my dll, > and give it to Bob, and then (and only then) (b) Bob can relink his app. > > Blech. Wait for the rules in my next mail. > > >>I shudder to think of maintaining all of that for the 200-odd DLLs that > >>come with KDE. > >> > > > > Using def files is unusable. > > > Unless it's the only way to avoid the problems above. Then, you ignore > the pain and just do it -- or write code to do it for you, like the > openoffice guys have done. > > > >>Then, there's one smaller problem: > >> > >>If you use a .def file to generate your DLL, will the auto-import stuff > >>get added to it? Can auto-import even work, if you're linking by > >>ordinal -- I thought the _nm_ hints were based on the symbol name, > >> > > > > no, the symbol name was build from the undef section, if a corresponding > > _imp_symbol was found, that means from the client side. There was no access > > (except of the dll name) to the implibs data. > > > Okay... > > > >>not the symbol ordinal... > >> > > > > I have patched auto-import stuff which got the ordinal from the implib. > > It works with the appended testcase. Currently I've build a new > working qt with > > this. > > > > > > In the second solution I have told about, using the regular implibs > and decide > > on a per case base > > if ordinal linking or not. > > > > I'm thinking about creating to areas, an internal and an external. > > New releases of kdelibs and perhaps kdebase for example are build > together. So > > ordinal linking is not problem. -> internal area. Any other app may > be linked by > > name -> external area. > > > Ah, so there'd be a special switch that KDE's internal makefiles use to > turn on 'link by ordinal' behavior; other applications would not use it, > and would thus link by name? (or, they'd use it and link-by-ordinal at > their own risk...) > > That seems workable to me. > > > > Second some dll's are only for specific apps for example konqueror > or kcontrol, > > which holds there code in some dll's. When rebuilding konqueror > the dll's could > > be linked ordinal without any problems, because there were all rebuild. > > > Errr...not so fast. Code reuse -- konqueror dlls can be linked into > other apps, can't they? -- or is all code reuse of that nature in KDE > done via KParts/Bonobo/CORBA/whatever, and not actual linking? > We will have to look at this a little deeper. Ralf
RE: ordinal linking for cygwin ld
> In the second solution I have told about, using the regular implibs and decide > on a per case base > if ordinal linking or not. > > I'm thinking about creating to areas, an internal and an external. > New releases of kdelibs and perhaps kdebase for example are build together. So > ordinal linking is not problem. -> internal area. Any other app may > be linked by name -> external area. If there are some rules, I think it is possible to manage this stuff. 1. Each KDE major release 2, 3 is to see as a single release with a fixed ordinal linking schema. This is archived by the kde-team, who said, that the kdelibs api is fixed for each major release except some enhancements, which are added. 2. kde packages are arranged into two groups, identified by the linking schema (ordinal or named) 3. packages, which belongs to the ordinal group needs special attention on basic libs updates. 4. packages, which belongs to the named group are less affected by updated basic libs. Relinking is only need by a major release change. 5. For each KDE major release the used ld release is fixed, except of updates not affecting the bfd/ld binary layout. Otherwise all packages of the ordinal group has to be relinked and released. 6. The packages of the ordinal group (and some of the named group) are maintained by the kde-cygwin team. 7. If an external one likes to maintain a package of the ordinal group he is responsible to follow topic 5. 8. Currently the following package belongs to the ordinal group: kdelibs, kdebase, kdevelop 9. basic library which should not be referenced ordinal, must not have import libs with ordinals. (This speeks against using ordinal in importlibs by default) Ld rules: 1. By default ordinal linking is disabled 2. Add an ld option to enable ordinal linking. As ordinal the hint number is used. (Could this have any unknown side effect ??) ordinal = hint number + 1. How should such an option be named ? Any comments ? Ralf
RE: ordinal linking for cygwin ld
> > If you use a .def file to generate your DLL, will the auto-import stuff > > get added to it? Can auto-import even work, if you're linking by > > ordinal -- I thought the _nm_ hints were based on the symbol name, > > no, the symbol name was build from the undef section, if a corresponding > _imp_symbol was found, that means from the client side. There was no access > (except of the dll name) to the implibs data. > Of course are the sections of the implib imported in the resulting binary, but currently I have an idea, how to save additional space in the implib. (for example the qt2.3.1 implib is about 8MB and contains 12079 symbols) At least each symbol name exist twice. Perhaps this can be put together d012073.o: i .idata$4 i .idata$5 i .idata$6 i .idata$7 t .text U __head_qt_2_3_dll (a) I __imp__y__C13QIconViewItem (b) T _y__C13QIconViewItem ->(a) __imp__y__C13QIconViewItem ^ (b) points to (a) + offset If this is possible there is no space need to build a import lib without names, because it will be a little about the half of the current size. I will see. Regards Ralf
Re: ITP: netpbm
As promised, take a look: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ The -src package contains --- a patch, which does the following three things: 1) creates a ready-made Makefile.config to implement the "policy" I described: INSTALL_PREFIX = /usr/local (line 469) - you'll want to change that to /usr PNGHDR_DIR = /usr/include (line 466) - you'll want to make that /usr/include/libpngXX if you use libpng-1.0.13 or libpng-1.2.2 LDSHLIB = -shared -Wl,--enable-auto-image-base (line 460) - you'll wnat to change that to -shared -Wl,--export-all since (1) auto-image-base is no longer recommended, and (2) export-all so you can take advantage of binutils' auto-export fucntionality INSTALLBINARIES = $(INSTALL_PREFIX)/bin/netpbm (line 474) - this is the big controversy 2) creates a CYGWIN-PATCHES/netpbm.README files which describes how to build [merged|normal][shared|static], and some analysis I did about which version is the most space efficient. 3) creates CYGWIN-PATCHES/shtool : netpbm is one of those packages that won't build outside of its own source tree, which complicates the script-driven build procedure. As mentioned here: http://www.cygwin.com/setup.html, I used GNU shtool's 'mkshadow' function to replicate the whole source tree inside the .build directory via symlinks. -src also contains: the build script, and the "pristine" tarball. But, this is all based on 9.24, not 9.25, so it would take some adaptation to use it, and merge my stuff with yours -- if you want it. Hope it's helpful. --Chuck Charles Wilson wrote: > Wonderful, please do. > > BTW, I have had a private version of netpbm, packaged in a > 'setup-compatible' way, for some time now. When I get home, I'll put my > version somewhere that you can access; you may want to expropriate some > of my patches... > > Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I > have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for > the ripples from the massive 1.0.13 packaging changes to settle out...) > > --Chuck >
RE: ordinal linking for cygwin ld
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 9:04 AM > To: Robert Collins > Cc: Ralf Habacker; Kde-Cygwin; Binutils; Cygwin-Apps > Subject: Re: ordinal linking for cygwin ld > > > Robert Collins wrote: > > > > > The PE spec (as I read it) indicates that as long as a name is > > included (ie it's not link-only-by-ordinal) then ordinals > can change > > and nothing will break. > > > > It's only when the only link information is the ordinal > that problems > > will appear. > > > That's what I thought, too, until I got bit. Check the > cygwin(-apps?) > ml archives during spring/summer 2000. At the time, the > symptoms seemed > like a smoking gun: link by ordinal == link ONLY by ordinal. OTOH, > binutils on cygwin was royally broken at the time, DJ was > transitioning > away from cygwin, Mumit had been gone for half a year or > more, and bit > rot was setting in. Yup. I was part of that conversation too :}. > Perhaps the problems that burned me then were due to broken > binutils/maintainerless cygwin-gcc, and it wasn't the smoking gun I > thought it was. IIRC it was never conclusively identified. > OTOH, if you've linked by ordinal, and then you strip symbols > -- are the > names of the imports still retained? Search me. Rob (cygwin sortof-binutils maintainer-it-would-help-if-I-knew-these-things).
Re: ordinal linking for cygwin ld
Robert Collins wrote: > > The PE spec (as I read it) indicates that as long as a name is included > (ie it's not link-only-by-ordinal) then ordinals can change and nothing > will break. > > It's only when the only link information is the ordinal that problems > will appear. That's what I thought, too, until I got bit. Check the cygwin(-apps?) ml archives during spring/summer 2000. At the time, the symptoms seemed like a smoking gun: link by ordinal == link ONLY by ordinal. OTOH, binutils on cygwin was royally broken at the time, DJ was transitioning away from cygwin, Mumit had been gone for half a year or more, and bit rot was setting in. Perhaps the problems that burned me then were due to broken binutils/maintainerless cygwin-gcc, and it wasn't the smoking gun I thought it was. OTOH, if you've linked by ordinal, and then you strip symbols -- are the names of the imports still retained? --Chuck
Re: ordinal linking for cygwin ld
Ralf Habacker wrote: > Ralf Habacker wrote: > >>I'm thinking about creating to areas, an internal and an external. >>New releases of kdelibs and perhaps kdebase for example are build together. So >>ordinal linking is not problem. -> internal area. Any other app may >>be linked by name -> external area. >> >> > That would cause the second solution I have told, normal import library and > using a special linker switch for using ordinal linking. Yeah, I think I like this -- but it should be used carefully in foundation libraries like KDE (and Gnome), and only where you're guaranteed that the ordinal-linked apps/dlls will always be upgraded together. The potential for muck-up is high... --Chuck
RE: ordinal linking for cygwin ld
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 8:55 AM > To: Ralf Habacker > Cc: Kde-Cygwin; Binutils; Cygwin-Apps > Subject: Re: ordinal linking for cygwin ld > > > Ralf Habacker wrote: > > >> > >>Since your app linked by ordinal, it will break if you try > to run it > >>with the new DLL, without re-linking. > >> > > > > accepted > > > > > >>So how does the vendor ensure that he doesn't unnecessarily break > >>backwards compatibility, and keep the ordinals the same? > By using a > >>def file. > >> > > > > Or be relinking all the libs. > > > If *you* release new "compatible" libs with the ordinals > different from > the current libs, *my* application breaks. Or, you might get ripple > effects: what if I distribute a dll that depends on KDE's > libs, and Bob > has an app that depends on my dll? Bob's app breaks because > my dll is > broken because you released new "compatible" libs. Not good > -- and it'd > take a while to track the problem down too: (a) I need to > relink my dll, > and give it to Bob, and then (and only then) (b) Bob can > relink his app. > > Blech. The PE spec (as I read it) indicates that as long as a name is included (ie it's not link-only-by-ordinal) then ordinals can change and nothing will break. It's only when the only link information is the ordinal that problems will appear. Rob
Re: ordinal linking for cygwin ld
Ralf Habacker wrote: >> >>Since your app linked by ordinal, it will break if you try to run it >>with the new DLL, without re-linking. >> > > accepted > > >>So how does the vendor ensure that he doesn't unnecessarily break >>backwards compatibility, and keep the ordinals the same? By using a def >>file. >> > > Or be relinking all the libs. If *you* release new "compatible" libs with the ordinals different from the current libs, *my* application breaks. Or, you might get ripple effects: what if I distribute a dll that depends on KDE's libs, and Bob has an app that depends on my dll? Bob's app breaks because my dll is broken because you released new "compatible" libs. Not good -- and it'd take a while to track the problem down too: (a) I need to relink my dll, and give it to Bob, and then (and only then) (b) Bob can relink his app. Blech. >>I shudder to think of maintaining all of that for the 200-odd DLLs that >>come with KDE. >> > > Using def files is unusable. Unless it's the only way to avoid the problems above. Then, you ignore the pain and just do it -- or write code to do it for you, like the openoffice guys have done. >>Then, there's one smaller problem: >> >>If you use a .def file to generate your DLL, will the auto-import stuff >>get added to it? Can auto-import even work, if you're linking by >>ordinal -- I thought the _nm_ hints were based on the symbol name, >> > > no, the symbol name was build from the undef section, if a corresponding > _imp_symbol was found, that means from the client side. There was no access > (except of the dll name) to the implibs data. Okay... >>not the symbol ordinal... >> > > I have patched auto-import stuff which got the ordinal from the implib. > It works with the appended testcase. Currently I've build a new working qt with > this. > > In the second solution I have told about, using the regular implibs and decide > on a per case base > if ordinal linking or not. > > I'm thinking about creating to areas, an internal and an external. > New releases of kdelibs and perhaps kdebase for example are build together. So > ordinal linking is not problem. -> internal area. Any other app may be linked by > name -> external area. Ah, so there'd be a special switch that KDE's internal makefiles use to turn on 'link by ordinal' behavior; other applications would not use it, and would thus link by name? (or, they'd use it and link-by-ordinal at their own risk...) That seems workable to me. > Second some dll's are only for specific apps for example konqueror or kcontrol, > which holds there code in some dll's. When rebuilding konqueror the dll's could > be linked ordinal without any problems, because there were all rebuild. Errr...not so fast. Code reuse -- konqueror dlls can be linked into other apps, can't they? -- or is all code reuse of that nature in KDE done via KParts/Bonobo/CORBA/whatever, and not actual linking? --Chuck
RE: ordinal linking for cygwin ld
Ralf Habacker wrote: > I'm thinking about creating to areas, an internal and an external. > New releases of kdelibs and perhaps kdebase for example are build together. So > ordinal linking is not problem. -> internal area. Any other app may > be linked by name -> external area. > That would cause the second solution I have told, normal import library and using a special linker switch for using ordinal linking. Ralf
RE: Correction for Setup.exe developer page
> -Original Message- > From: Max Bowsher [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 2:51 AM > To: Corinna Vinschen > Subject: Correction for Setup.exe developer page > > > The username for anonymous CVS is 'anoncvs', not 'anonymous'. Thanks!, corrected. Rob
RE: ITP: netpbm
> -Original Message- > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 6:03 AM > As for the # of executables in the /bin directory, isn't > there a limit to the number of files and/or directory entries > in any one directory on win32? As has already been said, not past the root. However directory search time is O(N) on FAT, vs (IIRC) O(logN) on NTFS. So directories with many files leads to signficcantly longer lookup times - and thas when the filename is known!. Rob
RE: ordinal linking for cygwin ld
Charles Wilson writes: > > Any comments ? > Yes: compatibility. The problem with ordinal linking is, suppose > version 1 of a DLL has the following exports: > > func_one @1 > func_two @2 > var_one DATA @3 > > and you link your executable to that dll by number. > > Now, the vendor releases a new version of the DLL with an additional > data export. Since no interface elements have been changed or removed, > only added, your app SHOULD be compatible with this DLL. But, if the > vendor isn't careful, the new DLL could end up like this: > > func_one @1 > var_two DATA @2 > func_two @3 > var_one DATA @4 > > Since your app linked by ordinal, it will break if you try to run it > with the new DLL, without re-linking. accepted > So how does the vendor ensure that he doesn't unnecessarily break > backwards compatibility, and keep the ordinals the same? By using a def > file. Or be relinking all the libs. > There's one big problem with that: > > def file are a @!#@^%@ to maintain. You *always* forget to add > something -- upstream maintainers are absolutely horrible about NOT > documenting all of the new functions/data exports that they add. So you > end up building the DLL with auto-export, use objdump to list the > exports, sort 'em, eliminate against your old .def file, create a new > .def file > > It's just a PITA. And one time, back when I was using .def files, I > actually managed, even with all of that effort, to release a DLL that > dropped one of the exports the OLD dll had, and broke everybody's app. > And I only deal with about 20 packages and DLLs. > > I shudder to think of maintaining all of that for the 200-odd DLLs that > come with KDE. Using def files is unusable. > Then, there's one smaller problem: > > If you use a .def file to generate your DLL, will the auto-import stuff > get added to it? Can auto-import even work, if you're linking by > ordinal -- I thought the _nm_ hints were based on the symbol name, no, the symbol name was build from the undef section, if a corresponding _imp_symbol was found, that means from the client side. There was no access (except of the dll name) to the implibs data. > not the symbol ordinal... I have patched auto-import stuff which got the ordinal from the implib. It works with the appended testcase. Currently I've build a new working qt with this. > IMO, the better "solution" is to provide a pre-load app, to load all of > the core KDE dlls into memory at bootup. This is what Netscape/Mozilla > now do, and what MS has been doing with IE for years: hide the load time > during the bootup sequence; at least that way, KDE/Moz/Ntsp/IE doesn't > get the blame... In the second solution I have told about, using the regular implibs and decide on a per case base if ordinal linking or not. I'm thinking about creating to areas, an internal and an external. New releases of kdelibs and perhaps kdebase for example are build together. So ordinal linking is not problem. -> internal area. Any other app may be linked by name -> external area. Second some dll's are only for specific apps for example konqueror or kcontrol, which holds there code in some dll's. When rebuilding konqueror the dll's could be linked ordinal without any problems, because there were all rebuild. Ralf > --Chuck > >
Re: ordinal linking for cygwin ld
Martin Hollmichel wrote: > Maybe you may look to openoffice.org how do the ensure that ordinals > keep the same over some time. There's a tool named ldump (located in > project tools, modules soltools) which keep's a database to keep the > ordinals in track. Maybe this helps. > at openoffice.org we're able to keep track of about 100 dll, maybe it's > usable for 1000 also. Well, if maintaining the .def files and ordinals is supported *from the top* -- as seems to be the case in openoffice -- then it wouldn't be so bad. I was trying to do it, for the cygwin project, "downstream" of the actual maintainers of certain unnamed packages (readlinencursesgettext). However, gcc only supports a subset of the .def file language that MSVC does, so one would either need to maintain two different .def files, or munge the cygwin/mingw one from the msvc one at build time (assuming the msvc .def file was maintained by the "real" KDE folks using some tool like yours). OTOH, I've never heard of a mingw or MSVC port of kde, so maybe KDE just needs cygwin .def files --Chuck
Re: ordinal linking for cygwin ld
Ralf Habacker wrote: > Any comments ? Yes: compatibility. The problem with ordinal linking is, suppose version 1 of a DLL has the following exports: func_one @1 func_two @2 var_one DATA @3 and you link your executable to that dll by number. Now, the vendor releases a new version of the DLL with an additional data export. Since no interface elements have been changed or removed, only added, your app SHOULD be compatible with this DLL. But, if the vendor isn't careful, the new DLL could end up like this: func_one @1 var_two DATA @2 func_two @3 var_one DATA @4 Since your app linked by ordinal, it will break if you try to run it with the new DLL, without re-linking. So how does the vendor ensure that he doesn't unnecessarily break backwards compatibility, and keep the ordinals the same? By using a def file. There's one big problem with that: def file are a @!#@^%@ to maintain. You *always* forget to add something -- upstream maintainers are absolutely horrible about NOT documenting all of the new functions/data exports that they add. So you end up building the DLL with auto-export, use objdump to list the exports, sort 'em, eliminate against your old .def file, create a new .def file It's just a PITA. And one time, back when I was using .def files, I actually managed, even with all of that effort, to release a DLL that dropped one of the exports the OLD dll had, and broke everybody's app. And I only deal with about 20 packages and DLLs. I shudder to think of maintaining all of that for the 200-odd DLLs that come with KDE. Then, there's one smaller problem: If you use a .def file to generate your DLL, will the auto-import stuff get added to it? Can auto-import even work, if you're linking by ordinal -- I thought the _nm_ hints were based on the symbol name, not the symbol ordinal... IMO, the better "solution" is to provide a pre-load app, to load all of the core KDE dlls into memory at bootup. This is what Netscape/Mozilla now do, and what MS has been doing with IE for years: hide the load time during the bootup sequence; at least that way, KDE/Moz/Ntsp/IE doesn't get the blame... --Chuck
Re: ITP: netpbm
Charles Wilson wrote: > > However, directories other than the root are unlimited in size (except > by your patience, and vision) > Given that, I think the usual /usr/bin directory should suffice. Earnie.
Re: ITP: netpbm
At 04:40 PM 4/26/2002, Charles Wilson wrote: >Larry Hall (RFK Partners, Inc) wrote: > >>At 04:03 PM 4/26/2002, Earnie Boyd wrote: >> >>>As for the # of executables in the /bin directory, isn't there a limit >>>to the number of files and/or directory entries in any one directory on >>>win32? >>I remember something vague about the number of entries in a directory on FAT (not >FAT32) partitions but I'm not sure whether it applies to files, >>directories, or both (probably both). Depending on what the restriction is, this >may be a good argument for being cautious of putting too much stuff in bin. Anybody >remember more about this FAT limitation? > > >You can only have 512 entries in the ROOT directory of a partition. However, long >file names take up more than one entry, so under VFAT this limitation is actually >worse than in FAT. > >However, directories other than the root are unlimited in size (except by your >patience, and vision) That's the ticket! OK, this is a non-issue then (good!). Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
RE: ordinal linking for cygwin ld
> 1. Currently I' have a working solution for binutils 20011002 using a > specific import library create with an -out-implib-ordinal option, > which contains only ordinals and no symbols in the > IMPORT_DESCRIPTOR_BY_NAME structure. (The patches and testcase are appended) The previous patch contains one undefinded var im pe.em, which is fixed with the current patch. Sorry Regards Ralf ld_ordinal_linking_3.patch Description: Binary data
new cygwin package: gnugo
Hello, I've uploaded binary and source packages of gnugo: http://home.quicknet.nl/qn/prive/ar.burgers/gnugo-3.2-1.tar.bz2 http://home.quicknet.nl/qn/prive/ar.burgers/gnugo-3.2-1-src.tar.bz2 The tarballs were prepared with generic-build-script.sh. No patch was required. category: Games requires: libncurses6 cygwin sdesc:"A program that plays the ancient game of Go" ldesc:"A program that plays the ancient game of Go Gnu Go can be used as is through an ascii interface. Much nicer is a GUI. See the Gnu Go website http://www.fsf.org/software/gnugo/ for more information." I hope this satisfies the requirements. regards Teun Burgers
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote: > At 04:03 PM 4/26/2002, Earnie Boyd wrote: > >>As for the # of executables in the /bin directory, isn't there a limit >>to the number of files and/or directory entries in any one directory on >>win32? >> > > I remember something vague about the number of entries in a directory on > FAT (not FAT32) partitions but I'm not sure whether it applies to files, > directories, or both (probably both). Depending on what the restriction > is, this may be a good argument for being cautious of putting too much > stuff in bin. Anybody remember more about this FAT limitation? You can only have 512 entries in the ROOT directory of a partition. However, long file names take up more than one entry, so under VFAT this limitation is actually worse than in FAT. However, directories other than the root are unlimited in size (except by your patience, and vision) --Chuck
Re: ITP: netpbm
At 04:23 PM 4/26/2002, you wrote: >Larry Hall (RFK Partners, Inc) wrote: > >>They can be accommodated by providing a script with the package that moves the files >elsewhere if this becomes a big issue, no? > > >upgrades? Run the script again. >Also, user customized installations belong in /usr/local; don't mess with /usr if you >want support from the list. OK, if you're suggesting this is an argument against the script I mentioned, fine by me. I don't think it's needed either. I was just trying to point out that there are alternatives for those individuals who preferred their installation of netpbm to go in other directories. I wasn't really proposing a specific solution. >I'd probably end up ignoring Jan's package and rebuilding my own version (which goes >into: > >/usr/local/bin/netpbm/* >/usr/local/lib/ >/usr/local/include/ >etc... > >Or maybe downloading Jan's -src package with each new release and rebuilding it after >changing the prefix...and the /bin/netpbm/ ... Right. That's an option too for those who want something different than setup would provide. I guess I can live with netpbm packaged with it's own bin directory if it handles adding the special directory to PATH and given that it is the exception to the rule like you mentioned. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
ordinal linking for cygwin ld
Hi all, one of the biggest problems with kde 2.2.x currently is the very bad loading time of applications and dll's, I've investigated some time to analyse this. On this way I recognized, that runtime linking using symbol names is one of the major time eater. At first I have tried to estimate the influence of symbol name to the runtime linking time. So I have build a dll 5000 functions and a client app, which uses this functions. This dll/apps are compiled in two variants, 1. with a symbolname lenght of a 13 characters and 2. with a symbolname lenght of 403 characters (should simulate long c++ names). cd shortname time ./client.exe real0m0.772s user0m0.030s sys 0m0.030s $ cd longname $ time ./client.exe real0m15.182s user0m0.060s sys 0m0.040s The result shows that this has a great effect of app/dll loading time (about 20 times more). After thinking a while about this, I remembered, that the windows pe format allows two runtime linking types. The first, usually used, is linking by the symbol name, the second is linking by symbols ordinal. A look in the last official cygwin ld (20011002) source shows, that linking by ordinal seems to be prepared with one limitation. There is no command line switch to create an import library for ordinal linking on dll building, so I've added a switch --out-implib-ordinal . (BTW: Another possibibily was automatic ordinal linking. See later) Now I've tried a second test. 5000 functions with symbolname lenght of 403 characters linked 1. with names and 2. with ordinals. 5000 functions with symbol name linking (symbols not stripped) $ time ./client.exe real0m15.182s user0m0.060s sys 0m0.040s 5000 functions with ordinal linking (symbols not stripped) $ time ./client.exe real0m0.572s user0m0.020s sys 0m0.030s Wow, thats great. 1. Currently I' have a working solution for binutils 20011002 using a specific import library create with an -out-implib-ordinal option, which contains only ordinals and no symbols in the IMPORT_DESCRIPTOR_BY_NAME structure. (The patches and testcase are appended) 2. Another possibility is using the regular import libraries hint number for ordinal linking (hint number = Ordinal number-1), but currently I don't know if this is always true. Solution 1 has an advantage on building big c++ libs, because the import library are smaller (about 20-50%). See the following example. The amount depends on the symbols count and length. old -rwxr-xr-x1 1002 Kein 1682944 Apr 22 09:42 /opt/kde2/bin/cygkdecore-3.dll -rwxr-xr-x1 1002 Kein 3190016 Apr 20 19:12 /opt/kde2/lib/libkdecore.dll.a new -rwxrwxrwx1 1002 Kein 1956812 Apr 26 22:03 libkdecore.dll.a -rwxrwxrwx1 1002 Kein 1608192 Apr 26 22:28 cygkdecore-3.dll Solution 2 is full compatible to dll's builded with previous ld, because the dll and import lib are still the same. Compiling an app with new ld will automatically use ordinal linking. The only necessary point seems to me a command line switch to switch of this behavior. Any comments ? Regards Ralf ld_ordinal_linking_2.patch Description: Binary data ld_ordinal_linking_testcase.tar.bz2 Description: Binary data
Re: ITP: netpbm
At 04:03 PM 4/26/2002, Earnie Boyd wrote: >As for the # of executables in the /bin directory, isn't there a limit >to the number of files and/or directory entries in any one directory on >win32? I remember something vague about the number of entries in a directory on FAT (not FAT32) partitions but I'm not sure whether it applies to files, directories, or both (probably both). Depending on what the restriction is, this may be a good argument for being cautious of putting too much stuff in bin. Anybody remember more about this FAT limitation? Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote: > They can be accommodated by providing a > script with the package that moves the files elsewhere if this becomes a big > issue, no? upgrades? Also, user customized installations belong in /usr/local; don't mess with /usr if you want support from the list. I'd probably end up ignoring Jan's package and rebuilding my own version (which goes into: /usr/local/bin/netpbm/* /usr/local/lib/ /usr/local/include/ etc... Or maybe downloading Jan's -src package with each new release and rebuilding it after changing the prefix...and the /bin/netpbm/ ... --Chuck
Re: ITP: netpbm
Earnie Boyd wrote: > So, I would like to see /usr/netpbm/bin. But I don't want to go all-out on the "separate package tree" idea. NO: /usr/netpbm/bin /usr/netpbm/lib /usr/netpbm/include /usr/netpbm/man /usr/netpbm/info Blech! YES: /usr/bin/netpbm/ << the only special case /usr/lib/ /usr/include/ /usr/man/ /usr/info/ XFree86 has a long history of a fully separate tree, and autoconf macros and suchlike have dealt with it for a long time. OTOH, netpbm has no such history (e.g. where to look for pbm.h? where to look for libpgm.a?) so development files should go in the "normal" place. But everything in the "normal" place under /usr/[lib,include,man], except for binaries in /usr/netpbm/bin/ ? That just offends my sense of aesthetics... Besides, we already have a history of /usr/bin/*/ that predates any of the mandates on http://www.cygwin.com/setup.html : ncurses-test-dll/ etc. --Chuck
Re: ITP: netpbm
At 03:57 PM 4/26/2002, Charles Wilson wrote:
>Larry Hall (RFK Partners, Inc) wrote:
>
>
>>I'm not sure why this makes more sense for this package than it would for
>>any package. So, to me, this is not a requirement for generating this package or at
>least not at this time, unless somebody can point out how
>>this package would be considered "special" in this regard.
>>In general, I don't see the advantage to having many "bin" directories,
>>at least insofar as it moves toward separate bin directories for every
>>package. It would just lead to the proliferation of directories in PATH or many
>complaints on this list stating "I installed X but when I run it,
>>it says 'X: command not found'!!!" I'd rather avoid either of these alternatives.
>
>
>Funny you should use 'X' as your variable. Think /usr/X11R6/bin/...
Yep, I'm good at things like that! ;-)
>I agree, we shouldn't worry too much about keeping /bin "clean" -- although
>distributions are moving towards putting stuff into /opt/pkg/* and making symlinks
>these days.
>
>However, IMO netpbm, like XF86, is a special case -- how many other packages have 223
>executable files and scripts? ("KDE" doesn't count; the KDE environment consists of
>lots of different packages; netpbm is one integral unit (or at most 4). And besides,
>doesn't KDE install into its own tree?)
OK, if you want to use the yardstick of "What's the convention on UNIX" as
a guideline, I guess that makes sense, excluding the free-for-all idea of
putting all packages in /opt/ptg/* and symlinking. Is there any de-facto
standard directory tree for netpbm in the UNIX world? If so, then maybe
it's worth adopting. If not, then I say it's best to just lump it all in
/usr/bin with everything else. Since it's an optional package, the number
of users that might prefer it otherwise will be a percentage of a percentage
of those who choose to install it. They can be accommodated by providing a
script with the package that moves the files elsewhere if this becomes a big
issue, no?
Larry Hall [EMAIL PROTECTED]
RFK Partners, Inc. http://www.rfk.com
838 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Charles Wilson wrote:
>
> Funny you should use 'X' as your variable. Think /usr/X11R6/bin/...
>
So, I would like to see /usr/netpbm/bin.
> I agree, we shouldn't worry too much about keeping /bin "clean" --
> although distributions are moving towards putting stuff into /opt/pkg/*
> and making symlinks these days.
>
Symlinks are slow for Win32, avoid them.
> However, IMO netpbm, like XF86, is a special case -- how many other
> packages have 223 executable files and scripts? ("KDE" doesn't count;
> the KDE environment consists of lots of different packages; netpbm is
> one integral unit (or at most 4). And besides, doesn't KDE install into
> its own tree?)
>
As for the # of executables in the /bin directory, isn't there a limit
to the number of files and/or directory entries in any one directory on
win32?
Earnie.
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote:
> I'm not sure why this makes more sense for this package than it would for
> any package. So, to me, this is not a requirement for generating this
> package or at least not at this time, unless somebody can point out how
> this package would be considered "special" in this regard.
>
> In general, I don't see the advantage to having many "bin" directories,
> at least insofar as it moves toward separate bin directories for every
> package. It would just lead to the proliferation of directories in PATH
> or many complaints on this list stating "I installed X but when I run it,
> it says 'X: command not found'!!!" I'd rather avoid either of these
> alternatives.
Funny you should use 'X' as your variable. Think /usr/X11R6/bin/...
I agree, we shouldn't worry too much about keeping /bin "clean" --
although distributions are moving towards putting stuff into /opt/pkg/*
and making symlinks these days.
However, IMO netpbm, like XF86, is a special case -- how many other
packages have 223 executable files and scripts? ("KDE" doesn't count;
the KDE environment consists of lots of different packages; netpbm is
one integral unit (or at most 4). And besides, doesn't KDE install into
its own tree?)
--Chuck
Re: ITP: netpbm
Gerrit P. Haase wrote: >>Okay, *two* more things: you may want to package this "the right way" >>from the beginning -- and avoid the pain I (and everyone else by proxy) >>went thru. Split out your DLLs from everything else and have two >>packages...'netpbm' and 'libpnmXX'. That way, when user bob builds >> > > Ohoh, that makes me nervous... > > If a new perl package gets released I probably should also release a > 'libperl-5.6.1' package which contains only the libperl-5.6.1.dll ? > Probably not - and here's why: (1) the DLLs are already versioned down to the micro level (2) anybody cluefull enough to actually build something against the perl DLL is cluefull enough to save the DLL version they need for their private package 'foo' before upgrading perl. Actually, given the interdependencies in /usr/lib/perl5/5.6.1/... I don't think the DLL is much use, without all the other stuff under /usr/lib/perl5/5.6.1/... So, in the case of perl, I don't think it makes much sense to split the DLL from the rest of the package. OTOH, allowing two perls to coexist might be a reasonable thing...perhaps the parrot should be released as 'perl6-6.x.y' and not 'perl-6.x.y'. --Chuck
Re: ITP: netpbm
Gerrit P. Haase wrote: > Thumbs up from me;) > > BUT: > Is it possible to put all the binaries into a separate directory > and not to flood /bin ? > > There are 223 .exe files (the scripts and .dll not counted)! > That's one of the things my setup-compatible private version did -- but since it was private, I could do whatever I wanted. In Jan's case...we need to discuss it. I vote for a special exception to the "all executables go in /usr/bin" rule specifically for netpbm. /usr/bin/netpbm/ for the exe's, but /usr/bin for the DLLs. --Chuck
Re: ITP: netpbm
At 02:38 PM 4/26/2002, Gerrit P. Haase wrote: >Jan schrieb: > > > Today I've taken a look at the netpbm package. Pierre Humblet, who's > > listed as Cygwin porter, is not considering to contribute it as Cygwin > > package, but was fine with me packaging it. > > > I've only done a few quick tests, from ps->pnm->png. URLs below. > > Cast your votes now. > >Thumbs up from me;) > >BUT: >Is it possible to put all the binaries into a separate directory >and not to flood /bin ? > >There are 223 .exe files (the scripts and .dll not counted)! I'm not sure why this makes more sense for this package than it would for any package. So, to me, this is not a requirement for generating this package or at least not at this time, unless somebody can point out how this package would be considered "special" in this regard. In general, I don't see the advantage to having many "bin" directories, at least insofar as it moves toward separate bin directories for every package. It would just lead to the proliferation of directories in PATH or many complaints on this list stating "I installed X but when I run it, it says 'X: command not found'!!!" I'd rather avoid either of these alternatives. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Charles schrieb: > Okay, *two* more things: you may want to package this "the right way" > from the beginning -- and avoid the pain I (and everyone else by proxy) > went thru. Split out your DLLs from everything else and have two > packages...'netpbm' and 'libpnmXX'. That way, when user bob builds Ohoh, that makes me nervous... If a new perl package gets released I probably should also release a 'libperl-5.6.1' package which contains only the libperl-5.6.1.dll ? Gerrit -- =^..^=
Re: ITP: netpbm
Jan schrieb: > Today I've taken a look at the netpbm package. Pierre Humblet, who's > listed as Cygwin porter, is not considering to contribute it as Cygwin > package, but was fine with me packaging it. > I've only done a few quick tests, from ps->pnm->png. URLs below. > Cast your votes now. Thumbs up from me;) BUT: Is it possible to put all the binaries into a separate directory and not to flood /bin ? There are 223 .exe files (the scripts and .dll not counted)! Gerrit > http://lilypond.org/cygwin/tar/netpbm/setup.hint > sdesc: "Graphics conversion tools" > category: Graphics > requires: cygwin jpeg libpng tiff zlib > # build-requires: cygwin jpeg libpng libpng-devel tiff zlib > ldesc: "Netpbm is a toolkit for manipulation of graphic images, including > conversion of images between a variety of different formats. There > are over 220 separate tools in the package including converters for > more than 80 graphics formats." > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 -- =^..^=
Re: ITP: netpbm
Oh, yeah, one other thing: runtime requirement is probably either libpng2 or libpng10, not 'libpng'. Build requirement is either libpng or libpng10-devel. (the first of each pair if 1.0.12, the second of each pair if 1.0.13). Okay, *two* more things: you may want to package this "the right way" from the beginning -- and avoid the pain I (and everyone else by proxy) went thru. Split out your DLLs from everything else and have two packages...'netpbm' and 'libpnmXX'. That way, when user bob builds gnuplot against your 'libpnm1' DLLs, his gnuplot will still work even after he upgrades to your newer netpbm package and libpnm2 DLLs -- because libpnm2 will (a) contain DLLs with names that are different from those in libpnm1, (b) can coexist on the same machine. Naturally, you'd only bump the libpnmX package number (and DLL numbers) when there was a backwards-incompatible change; ordinarily you'd just release a new libpnm1 package and overwrite the old DLLs with new-and-improved, but compatible, DLLs. Now that I think about it, you might want to split ALL of the DLLs into separate libpbmX, libpgmX, libppmX, libpamX packages -- IIRC the netpbm maintainer(s) follow different sequences on backwards compatibility on the libraries. There's no need to bump the "so" number and force new downloads of cygpbmX.dll, cygpgmX.dll, and cygpamX.dll, if only cygppmX.dll had a backwards-incompatible change... --Chuck Charles Wilson wrote: > Wonderful, please do. > > BTW, I have had a private version of netpbm, packaged in a > 'setup-compatible' way, for some time now. When I get home, I'll put my > version somewhere that you can access; you may want to expropriate some > of my patches... > > Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I > have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for > the ripples from the massive 1.0.13 packaging changes to settle out...)
Re: ITP: netpbm
Wonderful, please do. BTW, I have had a private version of netpbm, packaged in a 'setup-compatible' way, for some time now. When I get home, I'll put my version somewhere that you can access; you may want to expropriate some of my patches... Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for the ripples from the massive 1.0.13 packaging changes to settle out...) --Chuck Jan Nieuwenhuizen wrote: > Hi list, > > Today I've taken a look at the netpbm package. Pierre Humblet, who's > listed as Cygwin porter, is not considering to contribute it as Cygwin > package, but was fine with me packaging it. > > I've only done a few quick tests, from ps->pnm->png. URLs below. > Cast your votes now. > > Greetings, > Jan. > > > http://lilypond.org/cygwin/tar/netpbm/setup.hint > sdesc: "Graphics conversion tools" > category: Graphics > requires: cygwin jpeg libpng tiff zlib > # build-requires: cygwin jpeg libpng libpng-devel tiff zlib > ldesc: "Netpbm is a toolkit for manipulation of graphic images, including > conversion of images between a variety of different formats. There > are over 220 separate tools in the package including converters for > more than 80 graphics formats." > > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 > > >
ITP: netpbm
Hi list, Today I've taken a look at the netpbm package. Pierre Humblet, who's listed as Cygwin porter, is not considering to contribute it as Cygwin package, but was fine with me packaging it. I've only done a few quick tests, from ps->pnm->png. URLs below. Cast your votes now. Greetings, Jan. http://lilypond.org/cygwin/tar/netpbm/setup.hint sdesc: "Graphics conversion tools" category: Graphics requires: cygwin jpeg libpng tiff zlib # build-requires: cygwin jpeg libpng libpng-devel tiff zlib ldesc: "Netpbm is a toolkit for manipulation of graphic images, including conversion of images between a variety of different formats. There are over 220 separate tools in the package including converters for more than 80 graphics formats." http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Correction for Setup.exe developer page
The username for anonymous CVS is 'anoncvs', not 'anonymous'. Robert Collins <[EMAIL PROTECTED]> wrote: > http://sources.redhat.com/cygwin-apps/setup.html contains a brief page > for developers of setup.exe. > It's not aimed at replacing the packaging page > http://www.cygwin.com/setup.html, rather at folk who want to contribute > to setup.exe, or just rebuild it themselves. > > Anyway, the usual patches-gratefully-accepted applies. > > Rob
Re: setup changes to build standalone
Christopher Faylor wrote: > > On Fri, Apr 26, 2002 at 08:28:32AM -0400, Earnie Boyd wrote: > >This is good. IMO, there should be no binaries not dependent on > >cygwin1.dll in the /bin a.k.a. /usr/bin and that the /bin and /usr/bin > >directories be marked as --cygwin-executable. One reason for doing this > >is that it speeds the execution process for spawning by avoiding win32 > >translations. > > Yeah, there are now two binaries in /usr/bin, et al that are non-cygwin: > strace and cygcheck. If you have /bin and /usr/bin mounted with -X, it should speed > up execution of programs in that directory but it will screw up operation > of strace.exe and cygcheck.exe. > > I don't know how to fix that. Maybe there should be a /usr/ncbin or something. Yes, exactly. It's what I do for MSYS but the directory is /mingw/bin. > > > >Well, if you had a mingw32-gcc (cygwin hosted, mingw32 targeted) then > >you could use that instead of `gcc -mno-cygwin'. > > This would complicate the cygwin build process. We will always need > -mno-cygwin. > #!/bin/sh gcc -mno-cygwin ln -s ld.exe mingw32-ld.exe Earnie.
Re: setup changes to build standalone
On Fri, Apr 26, 2002 at 08:28:32AM -0400, Earnie Boyd wrote: >This is good. IMO, there should be no binaries not dependent on >cygwin1.dll in the /bin a.k.a. /usr/bin and that the /bin and /usr/bin >directories be marked as --cygwin-executable. One reason for doing this >is that it speeds the execution process for spawning by avoiding win32 >translations. Yeah, there are now two binaries in /usr/bin, et al that are non-cygwin: strace and cygcheck. If you have /bin and /usr/bin mounted with -X, it should speed up execution of programs in that directory but it will screw up operation of strace.exe and cygcheck.exe. I don't know how to fix that. Maybe there should be a /usr/ncbin or something. Hmm: Subject: Help I try to run the starce program like Larry Hlal said it and the cygwin says "stcrae: No such file or dirctorY"! Where I get this porgram? >> >>2) The above won't work in a cross build environment. You could say >> >> CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. >> > for cross compiles: >> > ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux >> > should do it (assuming a mingw32 cross compiler is present), or a >> > combination using the CC string you have above with the mingw host will >> > work too. >> >> whatever happened to the idea of an official cygwin package, that >> contained a true cygwin-host, mingw-target cross compiler? Didn't >> somebody or other volunteer to provide that? >> > >Oh, I thought about it sometime ago, I've been busy with MSYS and have >decided against my maintaining another package. Perhaps when Danny gets >3.1 up he can provide a Cygwin hosted Mingw32 targeted set of binaries. >I also remember a discussion on one of Cygwin's lists about using >scripts and symlinks to emulate this and may be the smartest way to go >about providing cross build emulation. > >> (Granted, we still need 'cygwin-gcc -mno-cygwin' for the "self-hosting" >> feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc >> -mno-cygwin for setup.exe, now that setup has been moved out of the >> winsup tree) > >Well, if you had a mingw32-gcc (cygwin hosted, mingw32 targeted) then >you could use that instead of `gcc -mno-cygwin'. This would complicate the cygwin build process. We will always need -mno-cygwin. cgf
Setup.exe developer page
http://sources.redhat.com/cygwin-apps/setup.html contains a brief page for developers of setup.exe. It's not aimed at replacing the packaging page http://www.cygwin.com/setup.html, rather at folk who want to contribute to setup.exe, or just rebuild it themselves. Anyway, the usual patches-gratefully-accepted applies. Rob
Re: Minor bugfix for setup.exe - missing call to backslash() in desktop.cc
You can avoid this by attaching a file with a .txt suffix.
Earnie.
Max Bowsher wrote:
>
> This adds a backslash() call to fix strange behaviour when creating the Cygwin
> link on the start menu.
> Currently, the link is created with name 'Programs/Cygwin/Cygwin Bash
> Shell.lnk'. NB: those are slashes in the filename, not directory separators.
> It's a minor bug, because once Windows notices this, it interprets the slashes,
> and moves it into the intended directory structure - nevertheless, it would be
> good to fix it. Accordingly, here are 1-liner patch and changelog. Patch is both
> inline and attached for convenience, since it is so small.
>
> My apologies for the ChangeLog not being indented properly - Outlook Express
> eats tabs.
>
> Max.
>
> ###BEGIN PATCH###
> diff -mru cvssetup/desktop.cc setup/desktop.cc
> --- cvssetup/desktop.cc Sun Mar 3 17:29:24 2002
> +++ setup/desktop.cc Sun Mar 3 17:23:41 2002
> @@ -143,7 +143,7 @@
> static void
> make_link (String const &linkpath, String const &title, String const &target)
> {
> - String fname = linkpath + "/" + title + ".lnk";
> + String fname = backslash(linkpath + "/" + title + ".lnk");
>
>if (_access (fname.cstr_oneuse(), 0) == 0)
> return; /* already exists */
> ###END PATCH###
>
> ChangeLog:
> 2002-04-26 Max Bowsher <[EMAIL PROTECTED]>
>
> * desktop.cc (make_link): Add backslash() for fname, so link is created
> in proper directory, rather than with slashes in its name.
>
> Max.
>
>
> Name: start-menu-shortcut-slashfix.patch
>start-menu-shortcut-slashfix.patchType: unspecified type
>(application/octet-stream)
> Encoding: quoted-printable
Minor bugfix for setup.exe - missing call to backslash() in desktop.cc
This adds a backslash() call to fix strange behaviour when creating the Cygwin
link on the start menu.
Currently, the link is created with name 'Programs/Cygwin/Cygwin Bash
Shell.lnk'. NB: those are slashes in the filename, not directory separators.
It's a minor bug, because once Windows notices this, it interprets the slashes,
and moves it into the intended directory structure - nevertheless, it would be
good to fix it. Accordingly, here are 1-liner patch and changelog. Patch is both
inline and attached for convenience, since it is so small.
My apologies for the ChangeLog not being indented properly - Outlook Express
eats tabs.
Max.
###BEGIN PATCH###
diff -mru cvssetup/desktop.cc setup/desktop.cc
--- cvssetup/desktop.cc Sun Mar 3 17:29:24 2002
+++ setup/desktop.cc Sun Mar 3 17:23:41 2002
@@ -143,7 +143,7 @@
static void
make_link (String const &linkpath, String const &title, String const &target)
{
- String fname = linkpath + "/" + title + ".lnk";
+ String fname = backslash(linkpath + "/" + title + ".lnk");
if (_access (fname.cstr_oneuse(), 0) == 0)
return; /* already exists */
###END PATCH###
ChangeLog:
2002-04-26 Max Bowsher <[EMAIL PROTECTED]>
* desktop.cc (make_link): Add backslash() for fname, so link is created
in proper directory, rather than with slashes in its name.
Max.
start-menu-shortcut-slashfix.patch
Description: Binary data
RE: setup changes to build standalone
> -Original Message- > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 10:34 PM > To: Robert Collins > Cc: Cygwin-Apps > Subject: Re: setup changes to build standalone > > > Robert Collins wrote: > > > > d) a --with-cygwin-headers=/path/to/headers and in mount.cc > pickup the > > needed headers. > > > > With a default of $(prefix)/include. Exactly. Rob
Re: setup changes to build standalone
Robert Collins wrote: > > d) a --with-cygwin-headers=/path/to/headers and in mount.cc pickup the > needed headers. > With a default of $(prefix)/include. Earnie.
Re: setup changes to build standalone
Charles Wilson wrote:
>
> Robert Collins wrote:
>
> > Yes. I even documented all this some time back on
> > http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but
> > predicatably enough, no patches where forthcoming. Probably due to the
> > complete lack of a prebuilt bz2lib for mingw (that my cursory searches
> > have looked for).
>
> https://sourceforge.net/projects/mingwrep/
>
I don't know if the maintainers of this site are still maintaining it.
Paul Sokolovsky isn't active any longer and Stefan Jahn isn't a MinGW
developer. This is one of those projects that I wish weren't. OTOH,
https//sourceforge.net/projects/mingw/ would be willing to upload any
MinGW package if it followed the --prefix=/mingw --host=mingw32
packaging rules (which unfortunately aren't documented except in the
mingw-dvlpr archives) and that person was willing to maintain the
pacakge (would need a SF account and be listed as a MinGW developer).
>
> >>I wonder if we need a "mingw-libs" package.
> >>
> >
> > Yes, please, please, yes. I would really really love it if some of the
> > common libs (zlib, bz2lib, stdc++) where available in a setup.exe
> > installable pacakge.
>
> Yes, I like this too -- but I'm nervous about it growing ridiculously
> large. What if (eventually) setup.ini turns into XML? Do we put a
> mingw build of libxml into 'mingw-libs'? How far does this go?
> (visions of full{mingw}.exe)
>
> OTOH, we've already discussed (and discarded, thank g-d) the idea of
> (for instance) the zlib maintainer providing both a
> cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
> /usr/lib/libz.[dll|a]) and a cygwin-setup-installable mingw-zlib package
> (/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto bzip2, libxml,
> ... we are not a mingw-porting factory.
>
This is good. IMO, there should be no binaries not dependent on
cygwin1.dll in the /bin a.k.a. /usr/bin and that the /bin and /usr/bin
directories be marked as --cygwin-executable. One reason for doing this
is that it speeds the execution process for spawning by avoiding win32
translations.
> >>2) The above won't work in a cross build environment. You could say
> >> CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess.
> > for cross compiles:
> > ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux
> > should do it (assuming a mingw32 cross compiler is present), or a
> > combination using the CC string you have above with the mingw host will
> > work too.
>
> whatever happened to the idea of an official cygwin package, that
> contained a true cygwin-host, mingw-target cross compiler? Didn't
> somebody or other volunteer to provide that?
>
Oh, I thought about it sometime ago, I've been busy with MSYS and have
decided against my maintaining another package. Perhaps when Danny gets
3.1 up he can provide a Cygwin hosted Mingw32 targeted set of binaries.
I also remember a discussion on one of Cygwin's lists about using
scripts and symlinks to emulate this and may be the smartest way to go
about providing cross build emulation.
> (Granted, we still need 'cygwin-gcc -mno-cygwin' for the "self-hosting"
> feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc
> -mno-cygwin for setup.exe, now that setup has been moved out of the
> winsup tree)
>
Well, if you had a mingw32-gcc (cygwin hosted, mingw32 targeted) then
you could use that instead of `gcc -mno-cygwin'.
> >>anything that is non-simple. I haven't looked at it in a
> >>while, though, so maybe things have changed.
> >>
> >
> > It really depends on what you want to do. Some stuff it does
> > spectalularly well, some things it has trouble with. With the 'cross
> > compiling but not' approach, it would almost certainly have some trouble
> > :}.
>
> see above, true cross compiler...
>
Or even the simulated with script and symlink one.
Earnie.
Setup now requires automake
I've checked in a automade (sic) version of setup. I may not have got all the headers just yet. bz2lib may need converting as well before we can 'make dist' completely, but the hard (not very :}) work is done. Rob
Re: ITP: swig-1.3.11-1
On Thu, Apr 25, 2002 at 02:43:49PM -0400, Gerald S. Williams wrote: > Obviously, more than just the FTP server was messed up. While > fixing a problem with their web-based HTML editing system, my > ISP somehow managed to delete all of my files AND change my > FTP password. >:o > > Perhaps it's a blessing in disguise. Since you hadn't gotten > it yet, I took this opportunity to replace the setup.hint as > I indicated earlier. > > Anyway, the files should all be there now... Ok, packaging looks fine, I've uploaded the files to cygwin.com. Please send an announcement to cygwin-announce according to http://cygwin.com/setup.html#submitting, section 9. Please send the announcement not immediately but in a few hours to give mirrors a chance. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: setup changes to build standalone
> -Original Message- > From: Jan Nieuwenhuizen [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 6:42 PM > > I'll have a look at some point. I actually find automake much less > > horrible that doing everything by hand. Anyway, this is > off-topic here > > - unless you are objecting to setup being automakified? > > No, it's rather off-topic, sorry. No problem, just ensuring we didn't end up in a -long- discussion about automakes +'s and -'s. Cheers, Rob
Re: setup changes to build standalone
"Robert Collins" <[EMAIL PROTECTED]> writes: > Sure. I'm not relying on gnu make features though. Yes, then things get a lot more awkward. > I'll have a look at some point. I actually find automake much less > horrible that doing everything by hand. Anyway, this is off-topic here - > unless you are objecting to setup being automakified? No, it's rather off-topic, sorry. > Ermm, most of my projects have much more than 10 lines just listing the > source. Yes, that's the price you pay when not using wildcards, but that can't be avoided. If you'd want to dist everything that's in cvs (ie, CVS/Entries), there could be a way out of that listing. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RE: setup changes to build standalone
> -Original Message- > From: Jan Nieuwenhuizen [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 6:19 PM > To: [EMAIL PROTECTED] > Subject: Re: setup changes to build standalone > > > "Robert Collins" <[EMAIL PROTECTED]> writes: > > > Heh. The main things I get from automake is > > a) make dist. I _love_ this so much it ain't funny. > > If you're willing to depend on gnu make features, make dist > is no rocket science. Sure. I'm not relying on gnu make features though. Also make dist-all while again, not rocket science, is very useful. And I'm -sure- that its more that 1 line to create that for each package. > Because of the horrors of automake, we've implemented a sane > set of make rules, mainly for LilyPond, that has all these > features and allows I'll have a look at some point. I actually find automake much less horrible that doing everything by hand. Anyway, this is off-topic here - unless you are objecting to setup being automakified? > > e) non-recursive makefiles of a reasonable size. > > a make file for a library or executable typically about 10 lines long. Ermm, most of my projects have much more than 10 lines just listing the source. (And before you bring up wildcards, I don't like them and wouldn't use them even if they where available in automake. I like knowing exactly what is in the package.) Rob
Re: setup changes to build standalone
"Robert Collins" <[EMAIL PROTECTED]> writes: > Heh. The main things I get from automake is > a) make dist. I _love_ this so much it ain't funny. If you're willing to depend on gnu make features, make dist is no rocket science. Because of the horrors of automake, we've implemented a sane set of make rules, mainly for LilyPond, that has all these features and allows > e) non-recursive makefiles of a reasonable size. a make file for a library or executable typically about 10 lines long. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
new setup checked in
The title pretty much says it all. If some folk could test the source, it should build with the command line I posted before. We'll likely need a setup specific web page with info in the near future. The CVS location is sources.redhat.com/cvs/cygwin-apps/setup. So for anonymous access use $ cvs -z3 -d :pserver:[EMAIL PROTECTED]/cvs/cygwin-apps co setup Cheers, Rob
RE: setup changes to build standalone
> -Original Message- > From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 2:25 PM > > On a separate but related topic, I'd like to automakeise (is that a > > word) setup - if there are no objections from the other > contributors. > > No, on the contrary I think that's a great idea. Raw > Makefile.in's scare the hell out of me. ;-) Heh. The main things I get from automake is a) make dist. I _love_ this so much it ain't funny. b) all the 'stock' rules - so that things like make clean _always_ hit all subdirs etc etc. c) consistent VPATH support. d) multicompiler dependencies (not that I personally use it much, I'm gcc most everywhere) e) non-recursive makefiles of a reasonable size. Makefile.in's aren't good or bad in raw form IMO. Rob
