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 i
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 i
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 ag
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 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 lat
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
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 glan
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 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 woul
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 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 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-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/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 tar
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:
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 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 tar
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
> MANPAT
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-lo
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 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.
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/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 same
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
> I'm expecting to make fu
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 oth
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
28 matches
Mail list logo
