On 6/11/2008 8:14 PM, SJ Kissane wrote:
In cygstart 1.4, cygstart --reference opens a web browser to
http://msdn.microsoft.com/library/en-us/shellcc/platform/Shell/reference/functions/shellexecute.asp
which microsoft redirects to:
http://msdn.microsoft.com/en-us/ms123402.aspx
which now
On 1/5/2010 11:48 AM, Charles Wilson wrote:
Personally, I dislike global static variables. It's also bad practice
with popt, because a single program can have multiple parsing contexts.
(Not that any of the cygutils tools do this; so if you want to globally
modify all cygutils popt-using
On 8/15/2010 5:26 PM, Andy Koppe wrote:
On 15 August 2010 22:11, Charles Wilson wrote:
So, if you want to forward port your locale/charset changes and
cleanup-handling changes for mkshortcut (probably as two separate
patches) I'll try to act on them more rapidly this time. :-)
So you'd
On 6/29/2009 2:53 PM, Andy Koppe wrote:
Shortcuts created by postinstall scripts using mkshortcut --allusers
--smprograms aren't readable for ordinary users, so all they get to
see in the start menu is a white dummy icon that doesn't do anything.
This affects both MinTTY and rxvt, at least
and mkshortcut.c to use cygwin-1.7 cygwin_conv_path
instead of deprecated cygwin_conv_to_win32_path.
* Update (some?) utilities to handle unicode filenames, similar to
IWAMURO Motonori's work on cygstart. Which utilities need this?
mkshortcut and lpr, probably. Any others?
--
Charles Wilson
volunteer
The libpng packages offer the standard libraries for manipulating
PNG files, a turbo-studly lossless image format. This is packaging
fix.
[[ compiled using gcc-4.3.4-3 ]]
CHANGES (since 1.4.3-1)
o Fix installation bug with import library (Yaakov Selkowitz)
--
Charles
and mkshortcut.c to use cygwin-1.7 cygwin_conv_path
instead of deprecated cygwin_conv_to_win32_path.
* Update (some?) utilities to handle unicode filenames, similar to
IWAMURO Motonori's work on cygstart. Which utilities need this?
mkshortcut and lpr, probably. Any others?
--
Charles Wilson
volunteer
The libpng packages offer the standard libraries for manipulating
PNG files, a turbo-studly lossless image format. This is packaging
fix.
[[ compiled using gcc-4.3.4-3 ]]
CHANGES (since 1.4.3-1)
o Fix installation bug with import library (Yaakov Selkowitz)
--
Charles
On 8/12/2010 11:30 PM, Yaakov (Cygwin/X) wrote:
libpng14-devel provides libpng.a and libpng.la symlinks, but no
libpng.dll.a symlink. I presume this is unintentional?
Yes. They changed the way these symlinks were done, to this:
for ext in a la so
On 8/11/2010 4:01 AM, Corinna Vinschen wrote:
On Aug 11 00:23, Charles Wilson wrote:
Can ssh (or is it cygwin1.dll?) ensure that the user's APPDATA variable
is populated, since it appears to be a pretty important var for Windows
Vista+?
In `man sshd' see the LOGIN PROCESS and SSHRC sections
The mingw.org folks are developing a new installer, which uses
WININET.dll facilities for d/l support. When I ran the application from
within a cygwin shell, I ended up with the following debris in my
testing /bin dir:
$ pwd
/c/msys-src/__xml/_test/bin
$ ls
libgcc_s_dw2-1.dll mingw-get.exe*
$
upstream release
+ Upstream ABI change bumps DLL version to '8'
o Include gentoo patch for memory limit detection
o Compile using gcc4; link using v2 pseudo relocs
--
Charles Wilson
volunteer jpeg maintainer for cygwin
To update
On 8/9/2010 8:15 AM, laurent.met...@cp.com wrote:
I have the same problem as described here (
http://sourceware.org/ml/cygwin/2010-02/msg00202.html) , with telnet
connection, there is no response.
Where can I find a fix for this issue ? I am currently using cygwin 1.7.5
and issue is still
upstream release
+ Upstream ABI change bumps DLL version to '8'
o Include gentoo patch for memory limit detection
o Compile using gcc4; link using v2 pseudo relocs
--
Charles Wilson
volunteer jpeg maintainer for cygwin
To update
On 8/8/2010 12:59 PM, Steven Monai wrote:
Some notes about the packaging:
The setup.hints of the libtorrent subpackages (libtorrent11 and
libtorrent-devel) are missing their 'external-source: libtorrent' line.
Odd...my local (modified) copy has these; I wonder if the patch I posted
for Chris
On 8/6/2010 11:52 PM, Chris Sutcliffe wrote:
I wish to maintain rtorrent and the additional libraries it requires
that are not currently part of the Cygwin distribution:
[snip]
All these packages have been approved by the Fedora project, but as
far as I can tell have not been included as part
On 8/7/2010 4:20 AM, Charles Wilson wrote:
The attached implement all of these suggestions. But the port builds
fine from source both with and without my modifications.
Oh -- and the setup.hints for the -doc, -devel, runtime, (and -lic)
packages are missing external-source: libsigc++2.0
On 8/6/2010 11:52 PM, Chris Sutcliffe wrote:
All these packages have been approved by the Fedora project, but as
far as I can tell have not been included as part of the official
Fedora distribution. However, it is part of Debian's stable packages
(lenny). As a result, I don't believe it
I noticed when compiling Chris' latest ITPs that if there is no binary
main package. That is:
libsigc++2.0-VER-REL-src.tar.bz2
libsigc++2.0-VER-REL.tar.bz2 empty package
libsigc++2.0_0-VER-REL.tar.bz2
etc
Then cygport will create that empty package automatically (in $topdir)
but does not copy
On 8/6/2010 11:52 PM, Chris Sutcliffe wrote:
I wish to maintain rtorrent and the additional libraries it requires
that are not currently part of the Cygwin distribution:
[snip]
All these packages have been approved by the Fedora project, but as
far as I can tell have not been included as part
On 8/7/2010 4:53 AM, Corinna Vinschen wrote:
On Aug 6 17:44, Charles Wilson wrote:
IIRC, just setting LDFLAGS before configuring won't do it, because
Bruno *deliberately* arranged things to make overriding his desired
auto-import behavior difficult.
So, just because he dislikes a gcc
On 8/7/2010 9:45 AM, Sisyphus wrote:
With cygwin-1.5.25 I can cross-compile libraries for native win32 by
starting with the following configure command:
./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin CC='gcc
-mno-cygwin' host_alias=i686-pc-mingw32
and that has worked fine on
)
o update to latest official release of libpng-1.2.x
o still using the non-autotools-driven build process
o compile using new gcc4 compiler
o updated hint files for new dependencies
o Move man pages from -devel to main package
o Don't install unversioned files
--
Charles Wilson
volunteer
-1.4.x
o ABI change upstream so DLL is now provided by the new
libpng14 package.
o Take this opportunity to switch to the autotool-driven
build. This results in the rather odd DLL name cygpng14-14.dll.
o Install unversioned files.
--
Charles Wilson
volunteer libpng maintainer for cygwin
)
o update to latest official release of libpng-1.2.x
o still using the non-autotools-driven build process
o compile using new gcc4 compiler
o updated hint files for new dependencies
o Move man pages from -devel to main package
o Don't install unversioned files
--
Charles Wilson
volunteer
-1.4.x
o ABI change upstream so DLL is now provided by the new
libpng14 package.
o Take this opportunity to switch to the autotool-driven
build. This results in the rather odd DLL name cygpng14-14.dll.
o Install unversioned files.
--
Charles Wilson
volunteer libpng maintainer for cygwin
On 8/6/2010 5:18 PM, Corinna Vinschen wrote:
On Aug 6 17:09, Christopher Faylor wrote:
Why not present as much info as possible? I don't know what libkate
is but it would be nice to be able to satisfy my curiousity on that page
rather than jumping to a web page and googling.
Well, that's
On 8/6/2010 4:20 AM, Markus Moeller wrote:
Can you tell me what the error means and what I can do to fix it ?
Thank you
Markus
Charles Wilson x...@xxx.xxx wrote in message
PCYMTNQREAIYR -
And please don't top-post:
A: Yes.
Q: Are you sure?
A: Because it reverses the logical
On 8/5/2010 3:09 PM, Chris Sutcliffe wrote:
libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin shared libraries
but I can't find any output from libtool to tell me what symbols are
undefined. Is there a way to find out what libtool is complaining
about?
There may not
On 8/4/2010 4:53 PM, Markus Moeller wrote:
I have an application which depends on gettext 0.18, but the latest
cygwin version is 0.17. When I try to compile 0.18 I get the below error.
Is that a known problem.
No, it isn't known; thanks for the warning. I'll look into updating
cygwin's
On 7/29/2010 3:21 AM, Peter A. Castro wrote:
Greetings,
A newish upstream version of zsh (and a test version) has been released.
Please upload:
Done. I added the following to the setup.hint:
curr: 4.3.10-1
test: 4.3.10dev2-1
prev: 4.3.9-1
On 7/30/2010 7:43 AM, Chris Sutcliffe wrote:
Please upload:
---
wget -x -nH --cut-dirs=1 \
http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.9-1.tar.bz2 \
http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.9-1-src.tar.bz2
Done.
--
Chuck
On 8/1/2010 1:56 AM, Chris Sutcliffe wrote:
Please upload:
---
wget -x -nH --cut-dirs=1 \
http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.11-1.tar.bz2
\
http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.11-1-src.tar.bz2
done.
--
Chuck
On 8/1/2010 7:25 AM, Reini Urban wrote:
I indent to maintain a new package rakudo-star,
which is a small addon to rakudo (aka perl6 on parrot).
387KB binary, 5MB src
Since I'm the first (in close contact with the developers) I need 5 votes.
The other distros: slackware and fedora are almost
On 8/1/2010 8:31 AM, Charles Wilson wrote:
On 7/29/2010 3:21 AM, Peter A. Castro wrote:
Greetings,
A newish upstream version of zsh (and a test version) has been released.
Please upload:
Done. I added the following to the setup.hint:
curr: 4.3.10-1
test: 4.3.10dev2-1
prev: 4.3.9-1
* Update to latest upstream version
* Compiled with gcc-4.3
* New dependency on libgcc1
--
Charles Wilson
volunteer zlib maintainer for cygwin
To update your installation, click on the Install Cygwin now link
* Update to latest upstream version
* Compiled with gcc-4.3
* New dependency on libgcc1
--
Charles Wilson
volunteer zlib maintainer for cygwin
To update your installation, click on the Install Cygwin now link
On 7/30/2010 2:55 PM, Ernest Mueller wrote:
We are trying to launch some Java apps from within Cygwin. The problem
we're having is that then Java file IO operations want to use Windows paths
and use \ as the default path separator. (This is different from classpath
problems or using
On 7/28/2010 11:22 PM, Yaakov (Cygwin/X) wrote:
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-patches-mXXj517/z...@public.gmane.org/msg05556.html
[RFT PATCH
On 7/28/2010 2:24 PM, Jon TURNEY wrote:
I have a tinderbox which does daily builds of the X.Org stack for
cygwin, and I've come across a something I don't understand with the way
libtool is working when building the pixman library, and I hope someone
can shed a bit of light.
On 7/27/2010 5:18 AM, Yaakov (Cygwin/X) wrote:
* with cross.cygclass, configure now uses --prefix=$sysroot$prefix
because of recently discussed issues with libtool and *-config scripts;
From Paolo's most recent version of his patches to provide sysroot
support in libtool:
On 7/26/2010 5:29 PM, Christopher Faylor wrote:
I'm not sure what the intent of the tilde in the name above was but
upset liked it and setup.exe didn't. I changed it to a '-' instead.
I'm not sure if I should modify upset or setup to deal with this. I
don't see any real need to have tildes in
On 7/26/2010 7:48 PM, JonY wrote:
its due in part to cygport's inherit svn template.
Not exactly.
IMHO either cygport shpuld be fixed to use - instead of ~ or setup
should be fixed to handle ~ in filenames.
setup uses whatever you use when you name the .cygport file.
I did this:
mv
On 7/25/2010 2:00 AM, Yaakov (Cygwin/X) wrote:
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 7/22/2010 8:47 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote:
Why shouldn't cygport allow that?
Thinking about this further, I think the problem is that we're talking
about two entirely different use cases:
1) cross-compiling a package to install
On 7/25/2010 5:01 AM, Yaakov (Cygwin/X) wrote:
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 7/24/2010 12:32 AM, Charles Wilson wrote:
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
[linux toolchain]
I'll try again, only this time using *your* linux-gcc pre-compiled
compiler package.
Same problem. Using Yaakov's latest
On 7/23/2010 1:54 AM, Yaakov (Cygwin/X) wrote:
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
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
[linux toolchain]
I don't think either of these two lines belong in the cygport:
mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1
On 7/15/2010 5:27 PM, Yaakov (Cygwin/X) wrote:
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
On 7/20/2010 8:46 PM, Yaakov (Cygwin/X) wrote:
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
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
The following flags are used in the official mingw compiler, but not here:
--enable-shared (but that's okay, as it is default)
--enable-libgomp
AFAIK --enable-shared
On 7/20/2010 9:55 AM, Dave Korn wrote:
On 20/07/2010 05:53, 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?
On the target?
I meant, *in what directory
On 7/20/2010 9:37 AM, Dave Korn wrote:
On 20/07/2010 06:26, Charles Wilson wrote:
On 7/19/2010 9:55 PM, JonY wrote:
With NLS you will still have at least partial translations, which is
better than nothing, no?
How about setting up --with-localedir to somewhere version or target
specific
On 7/19/2010 4:51 AM, JonY wrote:
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/gendef/gendef-20100719-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/gendef/libmangle-devel/libmangle-devel-20100719-1.tar.bz2/download
On 7/19/2010 2:23 PM, Charles Wilson wrote:
I tried to figure out get just the source you need via 'inherit svn'
-- but had to give up, since you want two *separate* subdirectories of
the top-level (mingw-w64-tools and mingw-w64-libraries), and perhaps
the top-level files, but you wouldn't
On 7/19/2010 9:43 PM, JonY wrote:
OK, I've tried the inherit svn method to separate both, and here are the
results:
gendef:
category: Devel
requires: libgcc1
sdesc: Generates exports definitions by analyzing executables.
^^^
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
I'll address issues with libtool/pkgconfig at that
time, as well (short version: our version of pkgconfig claims to support
sysroot via $PKG_CONFIG_SYSROOT_DIR, but newer versions have
On 7/19/2010 9:55 PM, JonY wrote:
With NLS you will still have at least partial translations, which is
better than nothing, no?
How about setting up --with-localedir to somewhere version or target
specific?
There isn't a '--with-localedir' option. But...there IS a --localedir
one. How
On 7/15/2010 1:50 PM, Yaakov (Cygwin/X) wrote:
As promised, here is my response to the mingw-w64 ITP.
cygport now supports several scenarios:
1) Cygwin-hosted (cross-)compilers, via toolchain.cygclass
This is exclusively for binutils, gcc, and gdb, either Cygwin-native or
any other
On 7/15/2010 11:42 AM, Dave Korn wrote:
I guess the first thing I should do is get out a
more vanilla-flavoured 4.5.0 release.)
Err... 4.5.1? Does the ABI breakage between 4.5.0 and 4.5.1/4.6.0
mentioned wrt x86_64-mingw affect i386, or cygwin?
--
Chuck
--
Problem reports:
On 7/13/2010 1:36 AM, Yaakov (Cygwin/X) wrote:
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
On 7/12/2010 1:49 AM, Yaakov (Cygwin/X) wrote:
On Sun, 2010-07-11 at 14:43 -0400, Charles Wilson wrote:
However, it's easier to walk before you run, so how about we get
everything nice and pretty with two (three, counting mingw.org) separate
non-multilib tool chains. Each would be built
On 7/12/2010 8:02 AM, Corinna Vinschen wrote:
On Jul 12 05:25, Yaakov S wrote:
On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote:
You're missing number 4. Cygwin and Mingw are targeting the same
underlying real target, which is Windows.
I wasn't actually missing it; I just
On 7/12/2010 6:19 AM, Yaakov (Cygwin/X) wrote:
I think I'm getting close to nailing down cross-compiling support in
cygport.
Great! (Is your current state checked in to git master or some other
branch?)
Throughout, the prefix=/usr assumption has been removed; *-*-mingw*
hosts use /mingw,
On 7/12/2010 6:06 PM, Yaakov (Cygwin/X) wrote:
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
On 7/9/2010 9:08 PM, Yaakov (Cygwin/X) wrote:
On Thu, 2010-07-08 at 10:34 -0400, Charles Wilson wrote:
Now, his ORIGINAL proposal was 64bit only, non-multilib. Maybe he'd be
pleased to go back to that; my feeling is he'd rather do multilib if
possible, but I'm not sure, and certainly don't
On 7/9/2010 12:54 PM, Christopher Faylor wrote:
On Thu, Jul 08, 2010 at 10:34:09AM -0400, Charles Wilson wrote:
On 7/7/2010 11:39 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote:
Hmm. That's what I *was* doing: JonY's -src provides a cygport that
I
/2010 8:59 PM, Dave Korn wrote:
On 08/07/2010 21:52, Charles Wilson wrote:
3) Now, if we want to have a *single* consolidated location for the $target
DLLs -- so that you can actually RUN the stuff you build,
Ah, that's your mistake, right there. It is only an accident that the
binaries we
On 7/9/2010 12:54 PM, Christopher Faylor wrote:
On Thu, Jul 08, 2010 at 10:34:09AM -0400, Charles Wilson wrote:
On 7/7/2010 11:39 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote:
Hmm. That's what I *was* doing: JonY's -src provides a cygport that
I
On 7/8/2010 3:22 AM, Corinna Vinschen wrote:
On Jul 7 18:24, Christopher Faylor wrote:
[...]
Whether we use w32api in the cygwin tree or from somewhere else really
doesn't matter as long as Cygwin builds.
That's why I'd like to know if Cygwin builds with w32api from the
mingw64 project.
On 7/7/2010 11:39 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote:
Hmm. That's what I *was* doing: JonY's -src provides a cygport that
I didn't mean the .cygport(5), I meant cygport(1). The goal is to make
these workarounds unnecessary.
Sure. There's
On 7/8/2010 1:09 PM, Dave Korn wrote:
On 07/07/2010 02:47, JonY wrote:
Locale data is also conflicting.
So can't it just go in $prefix/$target/share instead of $prefix/share after
a bit of fiddling with configure options?
I believe it will be fine, if you use a custom --datarootdir
On 7/8/2010 1:23 PM, Dave Korn wrote:
On 06/07/2010 19:56, Charles Wilson wrote:
To deal with the duplicated DLLs from two different multilib mingw64
toolchains (one that supports -m32 and -m64, but *defaults* to -m64, and
one that also supports -m32 and -m64, but *defaults* to -m32), the DLLs
On 7/8/2010 11:48 AM, Dave Korn wrote:
I'll be back in the Cygwin/GCC world starting next week.
YAY! We missed you, Dave. Welcome back!
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
[accidentally posted to the main list; re-sent here]
On 7/6/2010 10:35 PM, Yaakov (Cygwin/X) wrote:
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
On 7/7/2010 9:48 AM, Corinna Vinschen wrote:
On Jul 7 08:58, Christopher Faylor wrote:
On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote:
Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw*
sysroot idea. However, I don't like the idea in the least to keep
two
On 7/7/2010 11:12 AM, Corinna Vinschen wrote:
The important question for me is, can Cygwin be built using the w32api
based on the mingw64 sources?
Is it possible? Maybe; we'll just have to try it.
Is it legally permissible, given (possibly overblown?) concerns about
provenance of the changes
On 7/7/2010 5:03 PM, Christopher Faylor wrote:
On Wed, Jul 07, 2010 at 09:44:14PM +0100, Andy Koppe wrote:
On 7 July 2010 18:27, NightStrike wrote:
How's it built now?
With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api.
It doesn't use -mno-cygwin. How could it? The
On 7/7/2010 8:39 AM, Corinna Vinschen wrote:
On Jul 7 08:08, Charles Wilson wrote:
I hope I have summed up the various competing proposals fairly, and that
this edition of my patented War and Peace emails helps move the
discussion along to a conclusion.
Ok, I'm sufficiently confused now
On 7/7/2010 12:10 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-07-06 at 23:04 -0400, Charles Wilson wrote:
[massive snip]
OK, so the next question is, if they going to go multilib, why provide
TWO different toolchains -- basically identical, both supporting both
-m32 and -m64, different only
On 7/7/2010 8:14 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2010-07-07 at 15:21 -0400, Charles Wilson wrote:
Really? Other than the packaging issues, I had no problem with JonY's
src snapshot, compiling a 64bit-default, but multilib enabled, gcc. did
something break upstream between when JonY
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged binutils to add the /etc/profile.d scripts
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3
On 7/6/2010 3:48 AM, Yaakov (Cygwin/X) wrote:
On Mon, 2010-07-05 at 13:27 -0400, Charles Wilson wrote:
JonY needs to suppress the libtool fixup postinstall step when
packaging the mingw64 gcc. He may or may not need to fixup his .la
files, BUT -- given that we're talking about gcc here
As discussed in this subthread:
http://cygwin.com/ml/cygwin-apps/2010-07/msg00042.html
I think cygport needs a mechanism where you can override the
default_excludes used when cygport creates the .src.patch. Right now,
you can ADD files to the exclusion list using DIFF_EXCLUDES, but you
can't
On 7/6/2010 6:28 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-07-06 at 14:56 -0400, Charles Wilson wrote:
Which of the three interpretations best describes your current effort?
(1) and (2), as both are needed for mingw64. (3) is something
completely unrelated, nor am I sure how practical
On 7/6/2010 10:35 PM, Yaakov (Cygwin/X) wrote:
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
On 7/2/2010 2:36 AM, JonY wrote:
Here are the GCC links. I hope I got them all.
mingw64-m32-libgcc1-4.6.20100619-1.tar.bz2
mingw64-m32-libgfortran3-4.6.20100619-1.tar.bz2
mingw64-m32-libgomp1-4.6.20100619-1.tar.bz2
mingw64-m32-libobjc2-4.6.20100619-1.tar.bz2
OK, a bit further along. With the recently posted patch to cygport:
http://cygwin.com/ml/cygwin/2010-07/msg00117.html
AND the attached patch to your .cygport script, I get a bit further with
the install step. It completes without error (but I still have the
warning about the missing
Yaakov:
JonY needs to suppress the libtool fixup postinstall step when
packaging the mingw64 gcc. He may or may not need to fixup his .la
files, BUT -- given that we're talking about gcc here, AND his cross
compiler goes somewhere other than /usr...it's likely that whatever
fixing up he needs to
On 7/3/2010 2:28 AM, Andy Koppe wrote:
On 3 July 2010 03:07, Charles Wilson wrote:
Is mingw64 already part of a major Linux distribution? Otherwise it
needs five votes from Cygwin maintainers.
AFAICT, mingw64 is the mingw cross compiler provided by fedora.
Great.
Finally, I'm not sure
On 7/3/2010 1:44 PM, JonY wrote:
On 7/3/2010 11:27, Charles Wilson wrote:
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
It doesn't? I thought I saw -lz linked in for some executables. OK
On 7/3/2010 9:17 PM, JonY wrote:
On 7/4/2010 04:04, Charles Wilson wrote:
On 7/3/2010 1:44 PM, JonY wrote:
On 7/3/2010 11:27, Charles Wilson wrote:
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires
On 7/2/2010 1:41 PM, Andy Koppe wrote:
On 2 July 2010 08:17, JonY wrote:
OK to upload if packaging is fine, no changes needed.
Great to see mingw64 coming to Cygwin, but I think the upload should
wait until Cygwin gcc maintainer Dave Korn has had a chance to comment
on this.
I agree.
I am a little surprised that you got this to work simply by passing
--prefix=/opt/mingw64/... and a few other flags. Last time I looked
closely, cygport assumed /usr in quite a few places. Maybe that's
changed; if so, cool!
On 7/2/2010 1:29 AM, JonY wrote:
mingw64-tc64-headers:
...
category:
On 6/30/2010 7:12 PM, Charles Wilson wrote:
Do also give the ability to tell cygport to exclude some libtool files
from getting fixed up, thanks.
Again, I *think* you can suppress this; I'll check tomorrow.
No, apparently you can't (yet) do this. It's fairly easy to add,
though. I'll try
On 6/30/2010 3:50 PM, Charles Wilson wrote:
On 6/30/2010 1:51 PM, JonY wrote:
Right now, human intervention still needed. cygport messes up the target
dll locations by moving them around and trying to fix libtool files. Its
also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't
On 6/29/2010 7:50 AM, Corinna Vinschen wrote:
The files /usr/include/rpc/rpc.h and /usr/include/rpc/svc.h are provided
by the sunrpc package. Unfortunaltey Sam has resigned from the sunrpc
package maintainership and nobody has picked it up yet, so it's an
orphaned package which is in need of
On 6/29/2010 1:13 PM, JonY wrote:
On 6/30/2010 00:10, Charles Wilson wrote:
Now, I thought you wanted to use the w64 prefix as a project origin
indicator, and assumed that -mingw64- would be the target bitdepth
indicator. However, given w64-mingw64-pthreads-devel32 and
w32-mingw64-pthreads
801 - 900 of 3868 matches
Mail list logo
