On Wed, 2011-03-16 at 17:38 -0400, Charles Wilson wrote:
> So: I don't see any insurmountable problems with entirely replacing
> cygutils' unix2dos/dos2unix/u2d/d2u programs with these other versions.
> (I would hope that cygwin's package would provide a u2d.exe hardlinked
> to unix2dos.exe, etc)
On Sat, 2011-03-05 at 04:12 +0100, marco atzeri wrote:
> I am thinking to package CUnit: "A Unit Testing Framework for C"
> http://cunit.sourceforge.net/
>
> as it is needed for the build test of another package I am working on.
>
> and I am thinking that as this package is only needed during bui
On Fri, 2011-02-11 at 12:04 +0200, Jari Aalto wrote:
> New upstream release:
>
> wget --recursive --no-host-directories --cut-dirs=3 \
> http://cante.net/~jaalto/tmp/cygwin/xmlto/setup.hint \
> http://cante.net/~jaalto/tmp/cygwin/xmlto/xmlto-0.0.23-1-src.tar.bz2 \
> http://cante.net/~j
On Mon, 2011-01-24 at 11:54 -0500, Charles Wilson wrote:
> Err...why?
>
> exec_prefix=/usr/i686-pc-mingw32/sys-root/mingw
> sharedlibdir=$(exec_prefix)/bin
pkg-config does not substitute $(parenthesis), only ${curly_brackets}:
$ PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig
On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote:
> Updated packages are available by pointing setup.exe here:
> http://cygutils.fruitbat.org/ITP/mingw-gcc/
Could you sign your setup.ini and post the GPG key (for setup -K)?
> = mingw-zlib-1.2.5-4-src.tar.bz2
> = mingw-zlib-1.2.5-4.ta
On Tue, 2011-01-11 at 23:23 -0500, Charles Wilson wrote:
> On 1/11/2011 8:12 PM, Yaakov (Cygwin/X) wrote:
> > Why can't we keep things simple and just dump those outright? Aside
> > from nostalgia, what reason do we have to continue supporting gcc3 when
> > AFAIK no
On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote:
> -- 1 ---
> The first set of packages are revisions (actually, just rearranging the
> contents) of the venerable add-on packages that provide -mno-cygwin
> support for gcc-3.
Why can't we keep things simple and
On Thu, 2010-12-16 at 12:01 -0500, Charles Wilson wrote:
> cgf, any progress on creating a wrapper for mingw-binutils? If it's
> turning out to be difficult, could we go ahead with a "real"
> cross-configured mingw-binutils, and then maybe later update it with one
> that installs simple wrapper .e
On Mon, 2010-11-15 at 15:46 +0100, Jan Nieuwenhuizen wrote:
> I see you added
>
> +SCM_API int scm_i_terminating;
>
> I'm regularly building 1.8.7, I'll add your patch and release an
> update, would that be okay?
That will suffice, thank you.
Yaakov
On Sun, 2010-10-03 at 02:04 -0500, Yaakov (Cygwin/X) wrote:
> Cygwin's sqlite3 (3.6.21) is ten months old, and some current software
> already needs more recent versions. Could you please update sqlite3 to
> the latest upstream release (currently 3.7.2)?
Ping? KDE 4.5 requires a
On Wed, 2010-11-03 at 21:23 +0100, Lapo Luchini wrote:
> Dave Korn wrote:
> > In the meantime, I think that ocaml, ccache and distcc should remove gcc
> > from their setup.hint lines, and perhaps replace it by gcc-core.
>
> BTW: both 'ccache' and 'distcc' are depending on 'gcc' in latest
> setup
On Thu, 2010-10-28 at 18:21 -0400, Charles Wilson wrote:
> I've been using one of my own for a couple of months now (probably very
> similar to yours). I also worked thru the issues related to the "new"
> required locations of the "mingw-runtime/w32api for the mingw cross
> compiler" vs the "mingw
I think we agreed to proceed with transitioning from the old gcc-3
-mno-cygwin compilers to a true i686-pc-mingw32 cross-compiler
environment. This entails adding mingw-binutils, mingw-gcc (which would
replace gcc-mingw-3.x), and rebuilding mingw-* to use the sysroot
(including a new sysrooted min
On Fri, 2010-10-22 at 09:53 -0400, Andrew Schulman wrote:
> Yes, please remove 4.0.3-1 and 4.0.5-1. Thanks, Andrew.
Done.
Yaakov
On Thu, 2010-10-21 at 21:36 +0200, Christian Franke wrote:
> New upstream release
Uploaded.
Yaakov
On Thu, 2010-10-21 at 15:50 -0400, Andrew Schulman wrote:
> New upstream release. Please upload. Thanks, Andrew.
Uploaded. Can any of the older releases be removed?
Yaakov
On Tue, 2010-10-19 at 17:11 -0400, Andrew Schulman wrote:
> New upstream release of unison2.40. Please upload, leaving 2.40.16-2 as
> the previous release. Thanks, Andrew.
Done and done.
Yaakov
On Tue, 2010-10-19 at 17:18 +0200, Damien Doligez wrote:
> I have one remark about cygport:
> When stripping executables, you grep 'Caml1999X008' to determine if a given
> executable is an OCaml byte-code file. You should be aware that this magic
> number can get incremented from time to time when
On Wed, 2010-10-13 at 22:43 -0500, Yaakov (Cygwin/X) wrote:
> Enchant is a spell checking abstraction library supporting several
> backends. It is a requirement for several GNOME and KDE components and
> is already included in Fedora, Debian, and other major distros.
On Mon, 2010-09-27 at 02:28 -0500, Yaakov (Cygwin/X) wrote:
> On Thu, 2010-06-24 at 22:37 -0500, Yaakov (Cygwin/X) wrote:
> > Jan,
> >
> > Would you be able to update your guile package? Some software expect
> > newer versions nowadays, and I found at least one additio
On Fri, 2010-10-15 at 14:06 +0200, Damien Doligez wrote:
> This is the new OCaml, with Yaakov's fixes and suggestions.
> Please upload, and delete 3.12.0-3, keeping 3.08.1-1 as previous.
When creating a package containing one or more subpackages, it is
required that a particular directory layout b
Enchant is a spell checking abstraction library supporting several
backends. It is a requirement for several GNOME and KDE components and
is already included in Fedora, Debian, and other major distros.
ftp://ftp.cygwinports.org/pub/cygwinports/release-2/enchant/
Yaakov
On Thu, 2010-09-23 at 22:10 +0200, Lapo Luchini wrote:
> I compiled the new tidy library (shamelessly copying from CygPorts) and
> it's available here:
Lapo,
Do you plan to shamelessly copy nano from Ports soon as well?
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;
cocom is a build requirement for Cygwin, but is currently orphaned.
This looks to be pretty low maintenance, so I'll fix that:
ftp://ftp.cygwinports.org/pub/cygwinports/release-2/cocom/cocom-0.996-1-src.tar.bz2
ftp://ftp.cygwinports.org/pub/cygwinports/release-2/cocom/cocom-0.996-1.tar.bz2
ftp://f
On Tue, 2010-10-12 at 18:25 -0400, Robert S. Heckel Jr. wrote:
> New upstream release, shared libraries:
>
> wget -x -nH --cut-dirs=1 \
> http://bheckel.sdf.org/cygwin/libgc/libgc-7.1-1-src.tar.bz2 \
> http://bheckel.sdf.org/cygwin/libgc/libgc-7.1-1.tar.bz2 \
> http://bheckel.sdf.org/cygwin/libgc/
On Mon, 2010-10-11 at 21:22 -0400, Chris Sutcliffe wrote:
> On 11 October 2010 16:06, Yaakov (Cygwin/X) wrote:
> > Uploaded. Can we remove any older versions?
>
> Yes, please leave 0.9.10 as previous and feel free to remove all other
> versions.
Done.
Yaakov
On Mon, 2010-10-11 at 13:47 -0400, Chris Sutcliffe wrote:
> wget -x -nH --cut-dirs=1 \
> http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.11-1.tar.bz2 \
> http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.11-1-src.tar.bz2
Uploaded. Can we remove any older versions?
Yaakov
On Mon, 2010-10-04 at 16:35 -0700, David Rothenberger wrote:
> wget -x -nH --cut-dirs=2 \
>
> http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.3.10-1.tar.bz2
> \
>
> http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint
> \
>
On Mon, 2010-10-04 at 18:08 -0400, Chris Sutcliffe wrote:
> http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1.tar.bz2 \
> http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1-src.tar.bz2
Uploaded.
Yaakov
On Mon, 2010-10-04 at 17:54 -0400, Chris Sutcliffe wrote:
> http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1.tar.bz2 \
> http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1-src.tar.bz2
Uploaded.
Yaakov
On Sat, 2010-10-02 at 17:02 -0400, Ken Brown wrote:
> Please delete the 23.1-10 and 23.2-2 packages, leaving 23.2-3 as
> current and 23.2-1 as previous.
Done and done.
Yaakov
On Sun, 2010-10-03 at 17:51 +0100, Andy Koppe wrote:
> Please upload:
>
> wget http://mintty.googlecode.com/files/mintty-0.9.1-1.tar.bz2
> wget http://mintty.googlecode.com/files/mintty-0.9.1-1-src.tar.bz2
> wget http://mintty.googlecode.com/svn/tags/0.9.1/cygport/setup.hint
>
> 0.9b2-1 and 0.8.2
On Thu, 2010-06-24 at 22:37 -0500, Yaakov (Cygwin/X) wrote:
> Jan,
>
> Would you be able to update your guile package? Some software expect
> newer versions nowadays, and I found at least one additional variable
> that needs to be exported.
>
> Please feel free to u
On Thu, 2010-06-24 at 20:01 -0500, Yaakov (Cygwin/X) wrote:
> Bob,
>
> Your libgc package currently provides only a static library. Like most
> libraries, it should provide a shared version as well. Would you be
> able to update libgc accordingly? Please feel free to borr
On Thu, 2010-09-09 at 14:51 +0200, Damien Doligez wrote:
> I think you should upload this version for the moment because I have
> two potential problems with Yaakov's FlexDLL package that I need to
> investigate:
>
> 1. It's based on an old version of FlexDLL, and IIRC OCaml needs
>some of the
FlexDLL creates binaries whose symbols can be resolved at runtime,
despite the limitations of the PE format. It is required by OCaml for
dynamic linking support on Cygwin. This package contains patches to fix
data auto-imports, shared libgcc, and to remove some Win32-isms:
ftp://ftp.cygwinports.
On Tue, 2010-09-07 at 14:55 -0400, Christopher Faylor wrote:
> This has already been decided. I was just waiting for some sign of life
> from my friend the insight maintainer.
>
> I guess I'll go ahead and pull insight from the release. That should
> make things easier.
FWIW, Debian, Fedora, an
On Tue, 2010-09-07 at 15:01 +0100, Jon TURNEY wrote:
> On 07/09/2010 10:45, Yaakov (Cygwin/X) wrote:
> > This code does not compile with i686-pc-mingw32 gcc-4.5.1:
> >
> > postinstall.cc: In function ‘std::string
> > do_postinstall_thread(HINSTANCE__*, HWND__*)’:
>
On Mon, 2010-09-06 at 15:48 +0200, Damien Doligez wrote:
> 1. The tcl/tk bindings: they don't work out of the box with Cygwin's
>tcl/tk, and I don't think there is much demand anyway.
Interesting, given that OCaml presumes that Cygwin's tcl/tk is Win32
(which it currently is), but Ports' X11 t
On Fri, 2010-08-27 at 18:15 +0100, Jon TURNEY wrote:
> + // Remove anything which we just tried to run (so we don't try
> twice)
> + for (i = packages.begin (); i != packages.end (); ++i)
> +{
> + packagemeta & pkg = **i;
> + for (std::vector
On Sun, 2010-09-05 at 15:27 -0400, Charles Wilson wrote:
> Lapo, are you still here? Could we get an updated upx package, please?
I'm not so sure that he is still here. I've been asking for months now
for updates to lighttpd (security), nano (security, wchar support) and
tidy (latest release, sp
On Tue, 2010-08-31 at 17:34 -0400, Charles Wilson wrote:
> When testing JonY's mingw64 compiler, I found that often the include
> files ended up in the wrong directory.
Often?
> Also, JonY apparently did as well, since his cygport(5)'s
Which were likely borrowed from mine...
> included this b
On Sun, 2010-08-22 at 19:32 +0100, Andy Koppe wrote:
> Please upload:
>
> wget http://mintty.googlecode.com/files/mintty-0.8.2-1.tar.bz2
> wget http://mintty.googlecode.com/files/mintty-0.8.2-1-src.tar.bz2
>
> Please delete 0.8.1-1, leaving 0.7.1-1 as previous.
Done and done.
Yaakov
On Fri, 2010-08-20 at 13:51 -0500, Yaakov (Cygwin/X) wrote:
> OTOH, I do sometimes miss things on the main list due to the
> signal-to-noise ratio, which I imaging would be even greater for a
> maintainer with only a small number of packages. So using Bugzilla
> "internally&
On Fri, 2010-08-20 at 14:01 -0400, Christopher Faylor wrote:
> Can I get a show of hands? How many package maintainers would like to
> have a bug tracker?
Depends on how we use it.
Don't get me wrong -- I like working with Bugzilla, and we do use it
*internally* for Cygwin/X, but
Previous discussions (and my examples) on cross-compiling were focused
on other operating systems: MinGW, Linux, and Solaris. But there is
another use of cross-compiling: "bare metal" embedded systems.
Yesterday I built my first example of such: the AVR toolchain, a sample
build of which is now al
On Tue, 2010-08-17 at 11:54 +0200, Corinna Vinschen wrote:
> I have prepared a new release of vim, 7.3.002-1, so it's the new 7.3
> release from yesterday with its first two patches.
[snip]
> You can find the source and binary packages on sourceware under
> ~corinna/x/vim/
>
> Please ping me when
setup CVS HEAD (2.717) does not download test: releases in either
Install from Internet and Download Without Installing modes.
I found this out by trying to install gcc4-*-4.5.0-1; after selecting
the 4.5.0-1 versions of gcc4-*, they did not show up in the Pending
view, nor were they downloaded or
On Thu, 2010-08-12 at 01:07 -0400, Chris Sutcliffe wrote:
> libsigc2.0-2.2.8-1:
> libtorrent-0.12.6-1:
> rtorrent-0.8.6-1:
For some reason, your libsigc packages were 2.0-versioned but the
directories were not. I fixed this, moved them into release, and
updated cygwin-pkg-maint. Please announce.
On Wed, 2010-08-11 at 09:54 -0400, Christopher Faylor wrote:
> On Wed, Aug 11, 2010 at 03:16:58AM -0500, Yaakov (Cygwin/X) wrote:
> >The attached patch for bootstrap.sh makes it comparable to the typical
> >autogen.sh. Is this what you had in mind?
>
> Yes. Please go ahead
On Wed, 2010-08-11 at 01:11 -0400, Christopher Faylor wrote:
> I really don't know why we have something like doconfigure. Can't we
> just get rid of it?
Interesting point. Most software comes with one autogen.sh script,
which runs autotools and then configure; right now, we have separate
script
On Tue, 2010-08-10 at 21:32 -0400, Chris Sutcliffe wrote:
> libsigc2.0-2.2.8-1:
>
> wget -x -nH --cut-dirs=1 \
> http://emergedesktop.org/cygwin/libsigc/setup.hint \
> http://emergedesktop.org/cygwin/libsigc/libsigc2.0-2.2.8-1-src.tar.bz2 \
> http://emergedesktop.org/cygwin/libsigc/libsigc2.0-2.2.
This patch for setup contains a few build-system enhancements:
* Bail out of configure if prereqs are missing. I decided to check for
headers instead of libs to avoid possible stdcall issues with the
latter. I'm not sure whether this will make such a difference with
"gcc-3 -mno-cygwin" (which II
This patch fixes several issues compiling setup.exe with gcc-4.x while
retaining compatibility with gcc-3.4, as tested with gcc-mingw-3.4.4-999
and my mingw-gcc-4.5.1 sample build. Once we switch to a proper
mingw-gcc cross-compiler, the only change that will need to be made is
to CC/CXX in doconf
On Tue, 2010-08-10 at 13:33 -0400, Chris Sutcliffe wrote:
> > wget -x -nH --cut-dirs=1 \
> > http://emergedesktop.org/cygwin/libsigc++/setup.hint \
> > http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1-src.tar.bz2 \
> > http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1.tar
Right now, "make clean" (or the other *clean targets) does not clean in
libgetopt++. Unless there is something I'm not aware of, libgetopt++
can be handled like any other SUBDIRS, so that all targets are passed
down to it as well. Patch attached.
Yaakov
2010-08-10 Yaakov Selkowitz
* Makef
On Sun, 2010-08-08 at 19:33 +0200, Corinna Vinschen wrote:
> I just encountered a problem with the postinstall scripts of
> docbook-xml42 and docbook-xsl, an exit code of 1.
>
> Both postinstall scripts depend on the /usr/bin/build-docbook-catalog
> script which in turn calls
>
> xmlcatalog --n
http://cygwin.com/acronyms/#PPIOSPE !
Redirecting accordingly.
On Sun, 2010-08-08 at 20:42 -0700, Peter Li wrote:
> That's it; I had a little more to keep it compiling in other
> environments, but in any case it's very simple.
IOW:
#ifndef RTLD_LOCAL
#define RTLD_LOCAL 0
#endif
I actually hav
On Sun, 2010-08-08 at 20:10 -0700, Peter Li wrote:
> The Gnu Circuit Analysis Package has a stable version 0.35 from 2006
> and a very usable dev version from December 2009. I have found it
> useful in my work, and considerably easier than trying to compile SPICE
> or find a decent free SPICE b
On Thu, 2010-08-05 at 15:09 -0400, Chris Sutcliffe wrote:
> I've made good progress with libsgic++, but libtorrent is giving me
> grief in that it refuses to build the shared target (static is fine).
> What I get is:
>
> libtool: link: warning: undefined symbols not allowed in
> i686-pc-cygwin sha
On Thu, 2010-08-05 at 20:44 -0400, Chris Sutcliffe wrote:
> I've made some minor modifications to your packaging:
>
> ORIG_PN="libsigc++"
> inherit gtkmm
>
> HOMEPAGE="http://libsigc.sourceforge.net/";
> SRC_URI="http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.2/${ORIG_PN}-${PV}.tar.bz2";
gtk
mm-common provides a common build infrastructure for the GNOME C++
bindings (aka GTKmm). This is required at build-time for all packages
using gtkmm_autoreconf and gtkmm_compile.
mm-common is already in Fedora and Debian.
ftp://ftp.cygwinports.org/pub/cygwinports/release-2/GNOME/mm-common/mm-com
On Thu, 2010-08-05 at 12:02 -0400, Chris Sutcliffe wrote:
> I'm working on following the libtheora model:
>
> libsigc++-2.2.8-1.tar.bz2 (documentation)
> libsigc++0-2.2.8-1.tar.bz2 (runtime)
> libsigc++-devel-2.2.8-1.tar.bz2 (development)
Please API-version these, as there have been several
paral
On Thu, 2010-07-29 at 03:53 -0400, Charles Wilson wrote:
> From (patch v3-7/9):
> The = in func_replace_sysroot_result is the source of
> forwards-compatibility problems of older Libtools.
> Maybe --mode=finish could get rid of those. For platforms
> such as mingw w
On Wed, 2010-07-28 at 19:28 -0400, Charles Wilson wrote:
> From Paolo's most recent version of his patches to provide sysroot
> support in libtool:
>
> http://www.mail-archive.com/libtool-patc...@gnu.org/msg05556.html
> [RFT PATCH v3 3/9] add --with-sysroot
>
> Right now the default is to
On Sat, 2010-07-24 at 00:26 -0400, Charles Wilson wrote:
> What does gentoo do with cross compilers and sysroots? I know
> ebuild/emerge supports them; do they treat them strictly as support for
> cross compiles, or as installable images on the intended $host? I
> suspect the latter...
Not AFAIC
On Sat, 2010-07-24 at 10:34 -0400, Charles Wilson wrote:
> Same problem. Using Yaakov's latest pre-built linux cross compiler, and
> the latest linux-glibc src package, I attempted to rebuild.
>
> First I had the same problem where -jN was too aggressive on my quad
> core box, so I backed that dow
On Thu, 2010-07-22 at 22:50 -0400, Charles Wilson wrote:
> As noted here:
> http://cygwin.com/ml/cygwin-apps/2010-07/msg00175.html
>
> I was able to build setup.exe using i686-pc-mingw32-gcc and only
> setup-gcc45.patch (that is, without setup-no-autoload.patch) and it worked.
>
> The key differe
On Fri, 2010-07-23 at 16:32 +0100, Dave Korn wrote:
> I must be missing something. Shouldn't what's under the sysroot be
> basically an exact copy with the same layout as what would be on the host's
> own native filesystem? That's what I get from the description of
> --with-sysroot at http://gc
On Thu, 2010-07-22 at 22:41 -0400, Charles Wilson wrote:
> OK, so the libtool stuff is still percolating. Paolo just posted his
> patch series earlier today, so I haven't had a chance to test it out
> yet. However, it APPEARS after a cursory glance to work like this:
>
> 1) you configure stuff wi
On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote:
> But at SOME point, SOME part of what you've built on $host is supposed
> to be used, eventually, by somebody, on $target, right?
>
> Where should THAT live?
>
> If I'm on linux and have a devel environment, I can always compile with
> --p
On Tue, 2010-06-08 at 23:43 -0500, Yaakov (Cygwin/X) wrote:
> If genini is run from scratch (IOW without an existing setup.ini), no
> setup-timestamp: is generated, which leads to unexpected behaviour from
> setup.exe (e.g. "older than last time" warning).
>
> Patch attached.
Ping?
Yaakov
On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote:
> http://www.mail-archive.com/libtool-patches-mXXj517/z...@public.gmane.org/msg05488.html
> Paolo Bonzini mentioned that he had a different patch, and promised to
> rebase to latest and repost. He didn't. I pinged him.
Hopefully that comes
On Tue, 2010-07-20 at 08:43 -0400, Charles Wilson wrote:
> On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
> > AFAIK --enable-shared and --enable-libgomp are the defaults.
>
> Nope, apparently not. After making sure that pthread was installed in
> /usr/i686-pc-mingw32/sys-root,
On Tue, 2010-07-20 at 10:51 -0400, Charles Wilson wrote:
> Well, I guess the replacement package for the gcc(3)-mingw stuff can
> just create symlinks:
> /usr/lib/mingw -> /usr/i686-pc-mingw32/sys-root/mingw/lib
> /usr/include/mingw -> /usr/i686-pc-mingw32/sys-root/mingw/include
> (or,
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
> Overall, looks pretty good. I haven't used the new cygport(1) to build
> *any* native cygwin packages yet, however; so I haven't tested how well
> the new toolchain.cygclass works building the native cygwin toolchain.
If TOOLCHAIN_TARGET=
On Thu, 2010-07-15 at 12:50 -0500, Yaakov (Cygwin/X) wrote:
> The changes to cygport are extensive, and I have yet to break them out
> into reasonable-sized commits; so they're not on git yet, but I'm
> working on it. It is likely that I broke something along the way, so
>
On Thu, 2010-07-15 at 12:50 -0500, Yaakov (Cygwin/X) wrote:
> 2) Cygwin-to-other cross-compiling, via cross.cygclass
>
> Cross-compiling is supported for packages using autotools, cmake, or
> hand-written makefiles. Packages are automatically "installed" into the
> sysro
My test case for the mingw toolchain is, of course, setup.exe. I have
uploaded test builds of all mingw-* prereqs here:
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/
setup-gcc45.patch contains the changes necessary to compile and link
with mingw-gcc-4.5. However, the resulting setup.exe
On Thu, 2010-07-15 at 01:46 -0400, Christopher Faylor wrote:
> On Wed, Jul 14, 2010 at 06:54:41PM -0500, Yaakov (Cygwin/X) wrote:
> >On Wed, 2010-07-14 at 11:12 -0400, Christopher Faylor wrote:
> >> You know, back when I was distributing the mingw and w32api packages I
> >&
On Wed, 2010-07-14 at 11:12 -0400, Christopher Faylor wrote:
> You know, back when I was distributing the mingw and w32api packages I
> would have sworn that I put them in cross-compiler locations and created
> legacy symlinks back to the old /usr/include /usr/lib locations.
That would be possible
On Tue, 2010-07-13 at 03:53 -0400, Charles Wilson wrote:
> There is an "add-on" component that can be treated as part of the
> mingw64-crt-* build. You download it separately from reactos or wine, I
> don't remember, drop it in (a specific) place, and THEN configure and
> compile.
>
> Anyway, I wo
On Tue, 2010-07-13 at 09:51 +0200, Corinna Vinschen wrote:
> To be clear, there should be only one w32api under /usr/include and
> /usr/lib. That's the one used by Cygwin's non-cross gcc.
>
> Any other w32api used by the mingw cross gcc's should go under the cross
> target's sysroot.
Yes, that's
On Mon, 2010-07-12 at 22:45 -0400, Charles Wilson wrote:
> I don't really care either way about that one. What about things
> associated with $sysconfdir and $localstatedir? (e.g. /etc and /var are
> usually "outside" of $prefix). For cross (clients), suppress
> prep_etc_defaults, and assume $sy
On Mon, 2010-07-12 at 14:41 -0400, Charles Wilson wrote:
> Are we sure about this, given mingw64's express desire to avoid this
> $prefix -- specifically because "the other mingw" has historically used
> it, and "the other mingw" has had its preferences enshrined in the
> upstream gcc source cod
On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote:
> That's something I'll doo as soon as we really intend to switch the
> Cygwin build to mingw64's w32api. Right now, what I get from all the
> gory details, it's not that easy to keep mingw64's w32api headers and
> libs apart from the ming
I think I'm getting close to nailing down cross-compiling support in
cygport.
Throughout, the prefix=/usr assumption has been removed; *-*-mingw*
hosts use /mingw, everything else is /usr for now. (Anyone know any
specific systems where that's not the case?) Cross-compiled packages
are properly
On Sun, 2010-07-11 at 14:43 -0400, Charles Wilson wrote:
> How about this: suppose for the sake of argument that JonY *really*
> would rather the 64bit compiler, at least, also support multilib -- in
> the long run.
>
> However, it's easier to walk before you run, so how about we get
> everything
On Thu, 2010-07-08 at 18:27 -0400, NightStrike wrote:
> 4.5.x ABI and 4.6.x ABI are what differ, not 4.5.0 and 4.5.1.
>
> There's no point in making the first shipped compiler have an ABI
> that's already been changed. Hence 4.6.
Kai said differently on #mingw-w64; apparently it was treated as a
On Thu, 2010-07-08 at 10:34 -0400, Charles Wilson wrote:
> Unless Corinna/cgf really put their foot down and forbid multilib, I
> think we should defer to whatever JonY wants to do.
>
> Now, his ORIGINAL proposal was 64bit only, non-multilib. Maybe he'd be
> pleased to go back to that; my feeling
On Wed, 2010-07-07 at 11:33 -0400, Christopher Faylor wrote:
> >Here's my question, though: given the incompatibilities mentioned, would
> >a cygwin1.dll built with i686-w64-cygwin (mingw-w64) toolchain be 100%
> >compatible with current and past releases built with i686-pc-cygwin
> >(mingw.org) to
On Wed, 2010-07-07 at 08:58 -0400, Christopher Faylor wrote:
> Unfortunately, it sounds like we've stepped into the middle of a dispute
> between the mingw folks and the mingw64 folks. Maybe the best thing for
> us to do would be to decide to use only one or the other but not both.
It does seem t
On Wed, 2010-07-07 at 10:19 +0200, Corinna Vinschen wrote:
> So, is that ok to upload or are you going to change that first?
It's not wrong, just cleaner for the maintainer, that's all.
Yaakov
On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote:
> I'd want to check with Corinna on this but I am mildly opposed to putting
> this in /opt. I don't think it makes sense there. But I haven't been
> following closely, though. Where does Debian put these packages?
I'm working with Jon
On Tue, 2010-07-06 at 11:19 -0700, David Rothenberger wrote:
> I'd like to package libkate[1] in preparation for packaging the
> newest version of vorbis-tools.
>
> libkate is included in Fedora[2].
Looks good to me. FYI, instead of the custom src_install() to remove
KateDJ, you could define the
The last scheduled GNOME 2.30 release has been made, with GNOME 3.0 due
in September. GNOME 3.0 will still use glib2.0, atk1.0, pango1.0, and
gdk-pixbuf2.0 (which will be a separate source package again), but will
add new parallel-installable 3.0 versions of GTK+ and all GTK+-dependent
libraries.
On Thu, 2010-07-01 at 23:18 -0400, Chris Sutcliffe wrote:
> wget -x -nH --cut-dirs=1 \
> http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.8-1.tar.bz2 \
> http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.8-1-src.tar.bz2
Uploaded.
Yaakov
On Wed, 2010-06-23 at 21:35 -0400, Chris Sutcliffe wrote:
> wget -x -nH --cut-dirs=3 \
> http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.7-1.tar.bz2 \
> http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.7-1-src.tar.bz2 \
> http://emergedesktop.org/cygwin/googlecl/setup.hint
Seeing enough
On Wed, 2010-06-23 at 21:33 -0400, Chris Sutcliffe wrote:
> Thank you for the quick review and the tip on the cygport. I've
> uploaded new versions based on the revised cygport:
>
> wget -x -nH --cut-dirs=3 \
> http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.10-1.tar.bz2 \
> http://
On Wed, 2010-06-30 at 23:15 +0200, A.R. Burgers wrote:
> I've uploaded a 2nd try, simplified a lot.
> Thanks to Yaakov for his feedback.
>
> If ok this should supersede 1.1.8r5648-1, which should be left as previous.
> http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk1.1/setup.hint \
>
701 - 800 of 1060 matches
Mail list logo
