On Fri, 2010-07-09 at 12:54 -0400, Christopher Faylor wrote:
> I'm getting whiplash trying to read about these issues in cygwin-apps and
> cygwin. If Yaakov doesn't mind, I'd like to make discussions of cygport
> on-topic in cygwin-apps. It's sort of been that way for a while now anyway.
That's
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 didn'
On Fri, Jul 09, 2010 at 12:48:38PM -0400, Charles Wilson wrote:
>Let me quote cgf: "cygwin is not linux".
I usually say this when making things work like linux is very hard. I don't
see how that's the case here.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ:
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 didn't mean the .cygport(5), I meant cygport(1).
Since I appear to be alone in the "where should the compiler's runtime
DLLs go, when packaged for cygwin distribution" question, I'll bow to
the list consensus. I still think, tho, that using
/usr/[$target?]/sysroot/$target-shortname/{bin,lib,...}
like fedora-mingw does, as the $prefix for
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 compile with this particular cr
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 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
> are actually installed into a com
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 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
> appears to work. You have to impose some workarounds, like:
>
> RESTRICT=strip
>
> and manually use the target strip tool within src_install, but...it
> *works*. (E.g
On Wed, Jul 7, 2010 at 10:16 PM, Charles Wilson
wrote:
>> OOTB gcc multilib does not build, nor AFAICS do clear-cut patches exist
>> to fix it. Others in #mingw-w64 seem to think that multilib isn't worth
>> the headache, at least not yet. We'll see what I come up with over the
>> next few days,
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 J
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 took his snapshot and today,
> or are you refe
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 in the
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 in the default bitmode?
>
> Well...that's up to 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 Tue, 2010-07-06 at 14:56 -0400, Charles Wilson wrote:
> There are a couple of ways the term "cross-compiler support" could be
> interpreted.
>
> 1) support using cygport to compile packages using a cygwin-based cross
> compiler ($host=cygwin, $target=?). E.g. mingw-zlib built using
> i686-p
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, AND h
On 7/6/2010 15:48, 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, AND his
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, AND his cross
> compiler goes somewhere other th
On Mon, 2010-07-05 at 19:26 -0700, David Rothenberger wrote:
> I was just packaging a new version of libao and it turns out I need this
> patch, too. libao puts some plugin DLLs into /usr/lib/ao/plugins-2.
> Those DLLs are *not* marked as modules for some reason, so cygport tries
> to move them som
On 7/5/2010 10:27 AM, Charles Wilson wrote:
> 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 th
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
23 matches
Mail list logo
