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 down to
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 the
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 23/07/2010 01:47, Yaakov (Cygwin/X) wrote:
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 into the sysroot, to be used
solely on Cygwin for cross-compile other software, which would
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
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 to
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
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
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 -
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 with
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 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 and
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?
There isn't a '--with-localedir'
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?
Then package an /etc/profile.d script that appends or prepends to
MANPATH and
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 the
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 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, and rebuilding gcc:
I
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 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
I'm expecting to make
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
On 7/20/2010 09:49, Yaakov (Cygwin/X) wrote:
4. NLS. I think the cross toolchains should be compiled with
--disable-nls, if we can't figure out how to install and use the
correct .mo files associated with each compiler. Otherwise, all such
cross compilers must be at exactly the
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 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
sysroot (under $D).
The way I used
27 matches
Mail list logo
