This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport cross-compiling beta1


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 did I miss that?

There's still one issue that Yaakov brought up; it's not clear that
libintl will actually USE the correct version of the locale files...but
some experimentation should answer that question.

> iirc its used a bit in the cygnus tree to compile the cygwin1 dll and
> strace.

Not any more.

>>>     (also, --disable-werror,  and language Ada)
>>
>> Just hadn't bothered with Ada, that's all.
>>
> 
> Cygwin gcc needs to be bumped to around 4.5.0 to build it. Its stated
> somewhere in the GCC docs that you'll need the same version of gcc to
> build cross ADA.

Yep, that's why it's on DaveK's plate.  He'll probably keep the cygwin
native compiler and the mingw.org-based cross compiler in sync.

>>> I believe --enable-fully-dynamic-strings is correct, but apparently the
>>> official mingw.org 4.5.0 release does not use it.
> 
> Careful, this option causes ABI change.

Yes, and I had thought it had been used by all mingw.org post-4.x
releases, since the PR24196 patch was dropped (I still have the PR#
memorized...sheesh).

But I was wrong; mingw.org have been using neither that patch, nor
--enable-fully-dynamic-strings.  This means that if you link with the
static libstdc++, AND try to pass empty strings between DLLs, you may
crash. (If you link with shared libgcc/libstdc++, you're ok).

That's bad.  And it's why TDM's builds DO use
--enable-fully-dynamic-strings.

Here's the build recipe for mingw.org's 4.2.1-sjlj, which is the oldest
4.x one I could find:

../gcc-4.2.1-2-src/configure  --with-gcc  --enable-libgomp
--host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-sjlj
--with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw
--with-local-prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada
--disable-win32-registry --enable-sjlj-exceptions
--enable-libstdcxx-debug --enable-cxx-flags='-fno-function-sections
-fno-data-sections'  --enable-version-specific-runtime-libs
--disable-bootstrap
make BOOTCFLAGS="-O2 -D__USE_MINGW_ACCESS" CFLAGS="-O2
-D__USE_MINGW_ACCESS"  CXXFLAGS="-mthreads -O2" LDFLAGS="-s
-Wl,--stack=0x2000000"

And, as you see, it isn't using fully-dynamic strings.

So, I withdraw that suggestion.

>>> Is it usual to build linux compilers with
>>> --enable-fully-dynamic-strings?
>>
>> Apparently not, thanks for catching that.
>>
>>> Had to install libelf0 and libelf0-devel packages, in order to build.
>>
>> Right, as LTO uses libelf on ELF targets.
>>
> 
> just to clarify, win32 targeting GCC do not use libelf even when lto is
> enabled. A special coff lto module is used instead. Apparently elf
> readers don't work on coff :)

Right, JonY, in this section we were discussing the linux-$target
compiler, not the mingw*-$target ones.

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]