Robert Collins wrote:
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 21, 2002 8:33 AM
if you select the source for more than one of [bob|bobx|boby], then it
is downloaded only once (good) but is unpacked three times. This isn't
Robert Collins wrote:
All the content changes look great however. If you can clean up the
space to tab conversion, I'm happy for this to go in. However as it's a
change to the standard...
Any objections from any contributor?
Okay, I've made the corrections you mentioned. I had smart
Corinna Vinschen wrote:
I read them. It doesn't sound as if marking them current would
break anything (which is, OTOH, another set of famous last words)
so, go ahead.
Done.
--Chuck
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
c) rebuild the dll using your modified ld.
d) does the app still work, without
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
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,
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
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
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
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
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
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.
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,
Robert Collins wrote:
Can we detect libs and automatically exclude symbols from shared
libraries?
i.e. when linking against libcygwin.a, ALL symbols therein are from a
dll, so -by default- should not be exported.
Picky point: that's not true in this case. libcygwin.a, unlike most
Gareth Pearce 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?
As has already been said, not past the root. However directory search
time is O(N) on FAT, vs (IIRC) O(logN) on
Ralf Habacker wrote:
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
Charles Wilson wrote:
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
Charles Wilson wrote:
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:
If you go back to
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
you'll see I've
Christopher Faylor wrote:
On Sun, Apr 28, 2002 at 04:38:48AM +1000, Robert Collins wrote:
As usual, nothing is fixed in stone, and if this is a significant issue,
it can be revisited.
I have to agree with Earnie here. AFAIK, every other toolchain on
sources.redhat.com stores the
Gary R. Van Sickle wrote:
(thank the three men I admire most,
the Father, Son, and the Holy Ghost!).
Hah! An American Pie reference! Bye, bye Miss American Pie, Drove my
chevy to the levy but the levy was dry...
--Chuck
Corinna Vinschen wrote:
On Sat, Apr 27, 2002 at 06:04:55PM -0400, Larry Hall (RFK Partners, Inc) wrote:
But everyone will complain if they can't run the package after they install
it. I think we should absolutely avoid the latter case. The former
we can deal with as required.
What's
Robert Collins wrote:
-Original Message-
From: Stipe Tolj [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 1:10 AM
To: cygwin-apps
Subject: rebasing new packages?!
Hi there,
could someone of the gurus arround tell a (half-)guru :))
what the standard way would be if packages
Christopher Faylor wrote:
This wasn't entirely correct. The package name for XFree86-base
was Xfree86-base. Also, I would prefer if packages that relied
on X were put in the XFree86 hierarchy.
Also, Trevor Forbes suggested that X-dependent programs should be
compiled using
Be sure to read the p.s. ...
Christopher Faylor wrote:
On Fri, May 03, 2002 at 03:04:04PM -0400, Charles Wilson wrote:
Similarly, I don't like the restriction that all 'X'-based packages go
under XFree86/ on sourceware. We don't put inetutils underneath
ncurses/. We don't put openssh
Earnie Boyd wrote:
I see it's time for me to chime in. We the cygwin-apps developers must
insist that all X11 packages use --prefix=/usr/X11R6 because it's possible
for an X11 package to be both Win32 and X11, E.G.: rxvt. And I the user
could want to use either depending on the moode
Earnie Boyd wrote:
Bad example, Earnie. The current rxvt package is, itself, in a
single binary, BOTH Win32 AND X11. It is fine right where it is
(--prefix=/usr).
No, it's a good example. And you're correct the existing rxvt
package is fine right where it is. It's the one that
Earnie Boyd wrote:
(*) counter argument: gtk+ on cygwin currently uses X. However, the
code is THERE to use native MS windowing -- because there is a native MS
port (on a separate CVS branch). It might be possible, some time in the
future, to have TWO different gtk+ builds on cygwin: and X one
Corinna Vinschen wrote:
Question to the list: Should these modules go into subdirs
of release/apache/ or directly into release/ ?
I think the subdirs would make it clearer somehow...
subdirs, definitely.
--Chuck
Robert Collins wrote:
A new snapshot is available that address's this bug. Thanks to Fergus
Bonham for some detailed test reports that really helped track this
down.
Thanks to everyone who has persisted with setup while it had this bug...
No, thank *you* for being johnny-on-the-spot,
...seems to have problems. Can we please revert to 2.194.2.26 as the
production version, until this problem with the 218 branch is corrected?
When processing the setup.ini file from a local directory (actually on
a remote SMB share), it either
a) fails with a popup that says setup.exe has
Christopher Faylor wrote:
On Tue, May 14, 2002 at 10:40:19AM -0400, Charles Wilson wrote:
Still doesn't work when installing from a local directory (although it
works fine when installing from internet)
Once it begins parsing setup.ini, it dies almost immediately. But,
there is no warning
Teun Burgers wrote:
Hello,
I've uploaded binary and source packages of GSL,
homepage www.fsf.org/software/gsl/
These are the URL's of binary and source tarballs:
http://home.quicknet.nl/qn/prive/ar.burgers/gsl-1.1.1-1-src.tar.bz2
Corinna Vinschen wrote:
Packaging looks okay to me. For later releases, you might think about
re-enabling the libtool shared library support. But for now, the static
lib is great.
Could you upload the package, Charles?
Well, I said *packaging* looks okay. However, I object to the
Teun Burgers wrote:
I think this only affects the source package. I uploaded a new version
of that.
(You might have to reload the URL in order to avoid looking at a cached
copy)
http://home.quicknet.nl/qn/prive/ar.burgers/gsl-1.1.1-1-src.tar.bz2
This is the new setup.hint:
category:
Christopher Faylor wrote:
I have reservations about adding rsync support. This could easily cause
people to start using cygwin.com for everything and ignoring mirrors
since we allow anonymous rsync on sources.redhat.com.
:-(
I guess we could have setup.exe deny access to
Christopher Faylor wrote:
On Sun, May 19, 2002 at 02:51:22PM +0200, Dr. Volker Zell wrote:
See subject.
findutils-4.1.7-3 installs .mo files under /lib/locale/
instead of /usr/share/locale/
Thanks for the heads up. Should be fixed.
Enabling --auto-import for ld solved this problem.
Christopher Faylor wrote:
I lost track. Should I make a new release or are we waiting for
something new to be added?
I just rebuilt binutils and made --auto-import the default. Is there
a compelling reason for not doing this in the next release? I know that
--auto-import isn't perfect
Christopher Faylor wrote:
Can't you imagine all sorts of scenarios where a configure script, which
assumes normal unix linking of external symbols, becoming confused if
--auto-import wasn't on.
Of course. must get more sleep.
Second, why do you have to specify --auto-import for
Christopher Faylor wrote:
On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote:
1) Ralf's removing unused _nm_ symbol exports fix
2) Danny's (or Ralf's?) export-list fix (where whole static archives can
be marked for non-export, or DO export...helpful for convenience libs)
3
Danny Smith wrote:
I'd say go ahead and turn on auto-import in CVS and remove the
warning,
Chuck. I've gotten approval from Nick Clifton to do this if we
agree
it's a good idea.
It's obviously a good idea.
I disagree that is a good idea.
Two ideas:
1) making auto-import the default
Akim Demaille wrote:
|1) text from inside an AC_HELP_STRING() macro was NOT placed in the
|help section. Instead, it was just willy-nilly put into the script
|itself. Since help text is not, in general, valid shell script,
|this caused errors. Other AC_HELP_STRING()'s
Oops. Sorry for the crosspost. This actually belongs on the autoconf
mailing list. (Darned auto-complete put the wrong address in for Corinna).
But, since we're here:
It looks like my recent reports about problems with autoconf were
incorrect. Akim has nicely pointed out that PIBKAC.
Danny Smith wrote:
I think we should keep the warnings if --auto-import isn't specified
on the command line but get rid of them if it is explictly
specified. Including --auto-import on the command line would
indicate that the user knows what they're doing, so they don't
need to
No -- if zsh can handle cr+lf internally, then let it do so. Explicitly
open function files in binary mode -- this will override the textmode
mount which sets the default read mode.
That way, number of bytes reported by stat() will equal the number of
bytes reported by read(). The buffer
Attn maintainers:
There are a number of packages that list 'libpng' as a requirement.
However, that's probably incorrect. You probably want to depend on
'libpng10' (which contains cygpng10.dll) or 'libpng12' (which contains
cygpng12.dll) or 'libpng2' (which contains cygpng2.dll).
Also, some
Billinghurst, David (CRTS) wrote:
The prefix was /usr/X11R6. Fingers slipped in typing the mail.
The files are no longer at the URL given. I seem to have transgressed
some rule and the account has been closed. I will have to find an
alternative. (Suggestions welcome).
.
--Chuck
2002-05-30 Charles Wilson [EMAIL PROTECTED]
* ld/ldmain.c (main): initialize link_info.pei386_auto_import
to -1 == implicit enable.
* ld/emultempl/pe.em (gld_${EMULATION_NAME}_before_parse):
initialize link_info.pei386_auto_import to -1 == implicit
Christopher Faylor wrote:
On Thu, May 30, 2002 at 03:24:47PM -0400, Charles Wilson wrote:
Any comments here? Should I submit this patch to binutils, or can we
agree and commit from here?
Submit it to binutils, please.
done.
--Chuck
FWIW, it appears that this patch was committed on 21 May 2002.
--Chuck
Danny Smith wrote:
The previous post had incorrect subject heading. This is a repost. Sorry.
This is a refresh of:
http://sources.redhat.com/ml/binutils/2002-04/msg00472.html
The patch allows exclusion of
Ralf Habacker wrote:
When info-pei386_auto_import = -1 (default) then we continue to issue a
message when auto-importing a variable. If info-pei386_auto_import =
1, then we suppress those informational messages -- the user obviously
knows that she is auto-importing variables, since she
Christopher Faylor wrote:
Could everyone who has submitted a bug fix since the last release
provide a short paragraph describing what the bug fix related to?
I think it just boils down to fixes from Danny, Ralf, and Chuck,
AFAICT from the ChangeLog.
Please send the info to
Billinghurst, David (CRTS) wrote:
I'd prefer the re-autotool stuff to be part of the user build process.
I was going to propose this for ImageMagick, as it reduces the patches
from approx 1 Mb down to 2 lines. Much easier to understand.
IMO, this is a maintainer decision. If David wants
You probably should add a postinstall script to install-info the .info
files -- oh wait -- you could just rely on cgf's _install_info virtual
package to handle that...
Other than that, it looks good (although I'm a gpg newbie, so I haven't
actually tested *operation*...)
In the build script,
I propose to transfer maintainership of the popt and libpopt0 packages
to Nicholas Wourms. Nicholas has agreed to take over if the list
agrees. I think this is a good move for several reasons:
1) one less package for me to maintain (yippee!)
2) Nicholas is currently working with Gerritt and
Gerrit P. Haase wrote:
Hallo,
Expat is needed for the Perl module XML::Parser which is
used widely. Since it is not trivial to build it from
source with the latest release I provide a prebuilt package
for the Cgwin Perl community.
1) the docu should go into /usr/doc/expat-1.95.3/ not
You can also download this:
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/mingw-extra/mingw-extra-2.95.3_20011106-2.tar.bz2
and unpack it in the obvious place. It contains those libraries from
mingw's gcc package. You might also want to manually run the
postinstall
Charles Wilson wrote:
I propose to transfer maintainership of the popt and libpopt0 packages
to Nicholas Wourms. Nicholas has agreed to take over if the list
agrees. I think this is a good move for several reasons:
1) one less package for me to maintain (yippee!)
2) Nicholas
FYI, the new gettext package is NOT imminent. There are some variables
exported from cyggettext*.dll to the msg*.exe programs that are not
auto-importable. (direct access to elements in an array of structs).
So, I need to muck with the code some -- and add accessor functions or
something.
Corinna Vinschen wrote:
If only these two tools are using cyggettext*.dll and the other one,
why not linking statically against them? I don't see a reason to
have dlls hanging around for that purpose.
No, you got it backwards. There are only two programs -- the two MAIN
programs
Nicholas Wourms wrote:
Is xgettext.exe included or has that been phased out?
xgettext.exe is considered one of the development oriented tools, not
end user tools. So it's in the gettext-tools package (which I'm
calling gettext-devel).
--Chuck
Gerrit P. Haase wrote:
:-) Great. Well, I don't like the part about 'whining', but all the
rest is great.
Ok. I'll take the two packages if no one steps on my toes now...
Cool. I didn't mean that you, in particular, *must* take these two
packages or I won't do libiconv. It's just
Charles Wilson wrote:
Corinna Vinschen wrote:
If only these two tools are using cyggettext*.dll and the other one,
why not linking statically against them? I don't see a reason to
have dlls hanging around for that purpose.
No, you got it backwards. There are only two programs
Christopher Faylor wrote:
So, maybe I should rename the old version to gcc2 or release a version
of 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently.
Any thoughts?
I like this. 'gcc' ought to the the ongoing, 'current' package. If
folks want the old version, the
Christopher Faylor wrote:
On Tue, Jun 25, 2002 at 10:49:57AM +1000, Billinghurst, David (CRTS) wrote:
ditto for ImageMagick (it uses it too, and I could use an excuse).
I don't think there is any doubt that this will be useful. I'd say go
for it, Chuck.
Okay, it's uploaded.
Robert Collins wrote:
I've uploaded a new setup.exe snapshot. It's got some major parsing
changes... I don't think I've broken anything, but I'd appreciate
feedback :}. I have noticed that some 3rd party ini files fail to parse
- (prc-tools and cygutils specifically)
News to me. I eat my
Chris January wrote:
PLEASE do not differentiate between /bin and /usr/bin. This caused no
end of trouble during the early days of setup.exe when setup didn't
*always* follow the mounts. Granted, setup is much better about that
sort of thing now, but don't tempt fate.
There's no need for
Chris January wrote:
Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
I ended up renaming 'clear.exe' from the ncurses dist to 'clearn.exe' to
avoid conflicts with the 'clear' package. (In ncurses, 'clear.exe' is
not a 'test' program, so it didn't go into
egor duda wrote
CW But why is this cygwin-specific? It seems that it's equally applicable
CW to mingw (e.g. native) DLLs, just as mingw's gcc can use the current
CW auto-import feature, even though MSVC can't understand or use it...
Well, of course it shouldn't be. I was thinking in
Jan Nieuwenhuizen wrote:
Also, will libguile14-devel be able to peacefully coexist
with, say, libguile15-devel? Or should the -devel package be called
guile-devel' instead, so that only the latest version of the
headers/statlibs/implibs are ever installed?
To me, it sure looks like the latter
After looking at the build script, I remembered the cross-compiling
configuration build kit that Jan(?) developed.
http://lilypond.org/cygwin/cygwin-cross.tar.gz
This toolkit was used to generate the guile build script.
What it tells me is that we have too many ways of doing this. There's
Christopher Faylor wrote:
On Thu, Jul 04, 2002 at 04:13:10PM -0400, Charles Wilson wrote:
The two best candidates right now are probably the cross-tool at
lilypond, or cgf's mknetrel. Unfortunately, BOTH will require work --
lilypond's needs to play better on native platforms (as does
Dario Alcocer wrote:
Are there any guidelines or suggestions regarding packaging
source, patches and binaries for programs (like Ghostscript)
that can be built for either Cygwin or Cygwin/XFree86?
Not yet...
Unless I hear a very compelling reason to do otherwise, I'm
planning on
Charles Wilson wrote:
for non-x:
prefix = /usr
sysconfdir = /etc
CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
${srcdir}/configure \
--srcdir=${srcdir} --prefix=${prefix} \
--exec-prefix=${prefix} --sysconfdir=${sysconfdir} \
--libdir=${prefix}/lib --includedir=${prefix
Christopher Faylor wrote:
On Sat, Jul 06, 2002 at 07:02:31PM +0100, John Morrison wrote:
I would go ahead and allow ALL of the scripts and man pages to be
duplicated (bdftops, font2c, gslj, etc) into both /usr/bin/|/usr/man and
/usr/X11R6/bin|/usr/X11R6/man -- without any renaming.
Or
Dario Alcocer wrote:
For X:
prefix = /usr/X11R6
sysconfdir = /etc
CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
${srcdir}/configure \
--srcdir=${srcdir} --prefix=${prefix} \
--exec-prefix=${prefix} --sysconfdir=${sysconfdir} \
--libdir=${prefix}/lib
-
setup files:
#1)
ghostscript
requires: cygwin libpng2 zlib ghostscript-base
version: 7.05-1
You don't specify the version in setup.hint. You either
a) don't include any version info at all; upset will figure it out
b) specify using curr: prev:
David A. Cobb wrote:
I'm just a plain-nut! Would it be worthwhile, in your opinion, to look
at GNUpdate? At least, it doesn't carry any corporate baggage.
But we LIKE corporate baggage! And cygwin is part of a secret
government scheme to...well, another time, perhaps. And don't
Jan Nieuwenhuizen wrote:
* setting up the cross building environment.
There should be little, if any cross build environment to set up. You
either have the cross compilers or you don't.
I don't know what you mean by cross build environment. If you want
to build on linux you have to
Dario Alcocer wrote:
BTW, refresh me on the jpeg
problem? Why can't gs use the official cygwin library?
Here are the comments from unix-gcc.mak, Ghostscript 6.x:
# Choose whether to use a shared version of the IJG JPEG library (-ljpeg).
# DON'T DO THIS. If you do, the
Eduardo Chappa wrote:
Hello,
I am sending this message to request that a new version of Pine be
uploaded. The main reason for this upgrade is to add LDAP support, which
was not included in the first release. There are a few bug fixes
included too. Here are the relevant links:
Eduardo Chappa wrote:
*** Charles Wilson ([EMAIL PROTECTED]) wrote today:
:) A few important points:
:)1) Yes, Eduardo Chappa IS the official cygwin maintainer of pine --
:) At least, he was the guy who announce pine on cygwin-announce:
:)http://cygwin.com/ml/cygwin-announce
Christopher Faylor wrote:
libtool needs to *know* what linker is being used -- but (at least on
cygwin) it doesn't link using ld. It uses gcc.
But, libtool.m4 does cause configure.in/configure to test ld's
characteristics during configure -- and you want those tests to be
performed on the
Eduardo Chappa wrote:
*** Charles Wilson ([EMAIL PROTECTED]) wrote today:
:) No, it's just this: since I didn't recall your name, I wondered if
:) someone was hijacking the package. I vaguely remember somebody
:) rather petulantly asking for LDAP support, and was given a when
Jan Nieuwenhuizen wrote:
That's why I am investigating transitioning us to a cygwin port of
cvsnt (no, it's not just for native windows anymore...)
And it does work with emacs' pcvs.el, right?
Dunno. It's based on the cvs code; most of the changes are (a) bugfixes
-- what a concept (b)
Jan Nieuwenhuizen wrote:
The script is a requirement for Method2, and I'd like to slowly move
towards that packaging method.
http://www.cygwin.com/setup.html isn't written in stone. If we want to add a method
3 which is:
donwload current mknetrel
copy the included script 'pkgname'
Jan Nieuwenhuizen wrote:
Christopher Faylor [EMAIL PROTECTED] writes:
On Tue, Jul 09, 2002 at 02:14:16AM +0200, Jan Nieuwenhuizen wrote:
- fixes and preparations for building with libtool
Sorry, but I don't like this one. Does libtool *really* need to run
ld directly? That seems
Jan Nieuwenhuizen wrote:
Ah, now that would be smart thing to do, why didn't I think of that?
What about picking a directory for extra right now, let's say:
/usr/share/mknetrel/extra
and have individual packages all unpack their extra script there
(maybe even junk most extra's
Nicholas Wourms wrote:
Let keep the conversation about building a cross-compiler automatically
going. I think CGF is being rather stubborn about it and doesn't see
the potential benefits for the end user.
No need to be confrontational, Nicholas...
What probably should happen is
Nicholas Wourms wrote:
What about picking a directory for extra right now, let's say:
/usr/share/mknetrel/extra
and have individual packages all unpack their extra script there
(maybe even junk most extra's from mknetrel-cvs itself)?
Not yet. Since all of the scripts current in
Jan Nieuwenhuizen wrote:
But what I would like is
apt-get task-cygwin-devel
Exactly. Use the packaging tools native to the platform on which the
binaries will be installed. So, for a debian-hosted, cygwin-target
cross compiler environment: use dpkg/apt-get/whatever. For a Red
Jan Nieuwenhuizen wrote:
There just one small bugreport on -2, from Chuck, which has been
fixed, so I think this is it.
There was some delay because I had hoped, after spending the weekend
and yesterday night hacking on mknetrel, to junk my cygwin-cross tools
and use mknetrel for
Uploaded.
Dario Alcocer wrote:
On Mon, Jul 08, 2002 at 04:17:41PM -0400, Charles Wilson wrote:
Erm, you realize that the setup.hints are supposed to be *separate*
files, right?
Oops, no I didn't realize this. I've split the setup.hint into three
separate ones: gs-setup.hint, gs-base
Charles Wilson wrote:
Now, stop me if I get too 'method 2ish', but:
[snip]
unpack -src, giving:
foo-1.2-3.mknetrel
foo-1.2-3.patch
foo-1.2.tar.gz
Yes, this looks an awful lot like 'method 2' -- and we've got perfectly
good example shell scripts for doing things the 'method 2' way
Robert Collins wrote:
What I don't understand is the sudden rush. We are mere months away from
full deb or rpm support - why try to shoehorn the existing tarball
orientated tools into the same functionality these more mature tools have
developed?
Good point. There is no need to method
Robert Collins wrote:
My 2c: We settled on method 2 as a interim step before rpm or deb, to avoid
build yet another tool.
Doh! Correct.
Enough said.
Yep. Don't method 2-ize mknetrel
--Chuck
Jan Nieuwenhuizen wrote:
Hi,
I've added some terse doco in the code, but I feel that this
sub-package splitting could do with some documentation outside the
code, in a new file HACKING or PACKAGING. Or maybe a dummy example
package?
Using these patches (and the LD workaround), I've
Jan Nieuwenhuizen wrote:
Charles Wilson [EMAIL PROTECTED] writes:
I think your assumptions are probably safe, in general, and lead to a
nice understandable structure in mknetrel's code. I can double tar if
I need to.
I was just thinking: another reason for choosing this different
101 - 200 of 1203 matches
Mail list logo
