On 4/28/2011 22:56, Jon wrote: >>>>> Is LIBRARY_PATH ignored in my case because i686-w64-mingw32-gcc.exe >>>>> thinks it's cross-compiling between i686-w64-mingw32 and i686-pc-mingw32? >>>>> My understanding is LIBRARY_PATH is ignored when cross-compiling but not >>>>> other cases, and I want to make sure I get this issue before moving on. >>>>> >>>> >>>> No, the compiler doesn't work that way. >>>> >>>> The compiler you are using IS BUILT as a cross compiler, so it IS a >>>> cross compiler. Using autotools has nothing to do with it. >>> >>> Don't take this as beating a dead horse. I simply want to be clear on how >>> you're building these toolchains so I use them as you plan to build/support >>> them. >>> >>> I downloaded the "1.0 flavor" of mingw-w32-1.0-bin_i686-mingw_20110422.zip >>> which uses 4.5.3. It acted like a cross-compiler and didn't recognize >>> LIBRARY_PATH. Not a real problem as I simply switched to using CPATH, >>> PATH, and LDFLAGS and stopped using LIBRARY_PATH. Things are great except >>> for problems building OpenSSL :( >>> >>> However, I was a bit surprised when you said it's built as cross-compiler >>> since, from my perspective, it's effectively a mingw32 flavored compiler >>> targeting mingw32. >>> >>> Additionally, a friend that used the "non-1.0" (4.7.0-based snapshot) >>> flavor claims the compiler honors LIBRARY_PATH. The key difference is that >>> he manually removed the name prefixing from the executables before using >>> rather than polluting the environment as I did. >>> >>> I haven't yet been able to verify that the non-1.0 (4.7.0) compilers honor >>> LIBRARY_PATH while the 1.0 (4.5.3) compilers don't honor LIBRARY_PATH, but >>> it's next on my list. >>> >>> Would you summarize how you expect the versioned (1.0, etc) automated >>> builds and the non-versioned automated snapshot builds should behave wrt >>> LIBRARY_PATH? Also, please explain why they're being built as >>> cross-compilers as I'm not yet clear why they should be cross-compilers. >> >> Just because they appear to run on the system they target, it does not >> make it a non-cross. >> >> As far as I remember, i686-pc-mingw32 -> i686-w64-mingw32, still a cross >> compiler. >> >> We don't have native automated builds, we need more buildbots for >> hosting native builds. You can try sezero's toolchains if you need a >> native build, or just build it yourself, its not hard and its done >> frequently by other people. > > > Ah, I suspected build realities might be playing a part...makes sense. BTW, > I love how you guys are doing timely automated builds. > > re: cross and "Toolchains targeting Win32" automated builds, I agree except > in the "mingw-32...i686-mingw" cases. All other downloads (linux, cygwin, > darwin) are easily understood as cross. > > IMO your mingw downloads should behave (and I suspect many people expect them > to be) as non-cross; they run natively on 32-bit Windows and build native > 32-bit Windows artifacts. Conceptually, your 32-bit mingw downloads are no > different from the mingw.org or tdm-gcc non-cross tools. Ideally, mingw-w64's > (in this 32-bit Windows environment) shouldn't break existing builds by > behaving as cross where non-cross is legitimately expected. > > For such reasons I ask that you reconsider changing the automated 32-bit > mingw builds to non-cross. That said, given project realities I also think a > detailed FAQ entry would minimize surprises as I suspect many would be OK > switching from LIBRARY_PATH to LDFLAGS. >
I have already mentioned, we lack the resources to commit automated native builds. I still think using LIBRARY_PATH is more of a hack, one should always supply parameters by command-line instead of relying on environment variables. Sezero already puts out native toolchains once in a while. > Self building is not an good option for my scenario. I'm currently folding in > support for this toolchain into a larger project > https://github.com/oneclick/rubyinstaller/blob/mingw64-32/config/compilers/mingw64.rb#L3-34 > in which our build recipe will download your toolchain, combine it with MSYS > and other key artifacts, and use the resulting amalgamation to build the > project as well be the engine in an easy-to-use DevKit > https://github.com/oneclick/rubyinstaller/wiki/Development-Kit. > Than I think of all those users using outdated copies streaming in and reporting bugs fixed months ago :| Anyway, by bundling a toolchain, will you be willing to maintain it at your end? I noticed you are mixing mingw.org components in, be careful not to mix them when linking, there is no guarantee it'll work out. > Thanks for all the effort and your time...we like what we see so far in > mingw-w64 :) > Sure, NP.
0xED74C077.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
