Ok, the first build of the new location setup.exe is available at:
http://www.cygwin.com/setup-snapshots/setup-newlocation.exe.
Please report any aberrant behaviour ASAP.
Works for me :}.
Rob
-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
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
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
-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
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
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
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
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.
-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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
-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
-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
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
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.
-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
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.
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,
-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
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
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
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
-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
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
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
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 ?
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
-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
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
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
-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
-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
55 matches
Mail list logo
