>
>
>
> > -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?
>
>A
> -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
> incor
> -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
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/winsu
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
> -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 s
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
>
>
>
>
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 introdu
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
> > 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
> 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 (
> -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 a
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
>
> 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
> 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 linki
> > 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
> _
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)
-
> -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
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 thou
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 -> externa
> -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 ordi
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
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
> -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
> -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 bee
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 ne
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 openoff
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
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.
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
> 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 conta
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
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
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 /u
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 th
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 b
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
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
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
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
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 consider
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 use
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
sin
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,
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 b
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.
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 w
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,
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
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, rath
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
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 ex
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-gratef
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
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 t
> -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 m
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.
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
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
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
> -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 o
"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
> -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
"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
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
> -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 contrar
66 matches
Mail list logo
