On Wed, Nov 14, 2012 at 12:57:07PM +0100, Corinna Vinschen wrote:
>On Nov 13 22:39, Christopher Faylor wrote:
>> Try #3. This is a smaller patch with some bug fixes found after
>> building from-scratch, cleanly on a Fedora system with Yaakov's cross
>> tools (ok, so I lied and did end up setting up a Fedora system to test
>> this).
>
>Is that the point where I have to say "na na na na naaa na"? Just kidding.
>
>> Also fixed some long-standing Makefile bugs and misconceptions in
>> cygwin and utils.
>>
>> I'm not entirely thrilled with the fact that configuring and building
>> this from the level above winsup results in lots of compiler command
>> line parameters passed in which are also discerned by macros in
>> acinclude.m4. If we do end up staying in the src CVS repository I'll
>> have to fix that.
>
>For a start I applied the patch to CVS HEAD and ran a stock `configure;
>make' from toplevel on Fedora 17 with Yaakov's Cygwin packages.
>
>I can't link the Cygwin DLL:
>
>/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot
>find -luser32
>/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot
>find -lkernel32
>/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot
>find -ladvapi32
>/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot
>find -lshell32
>collect2: ld returned 1 exit status
>
>I didn't look why it doesn't find these libs. But this means the
>-nostdlib flag is missing.
AFAIK, it means that the -nostdlib is used and the path to the libraries
isn't right. It is when you specify the windows library path
explicitly. This should be fixed now. Finding the path to where the
linker locates libraries turned out to be harder than it first appeared.
>If I add it I get a lot of messages pointing out missing symbols,
>though:
>
>.../cygtls.h:301: undefined reference to `__Unwind_Resume'
>.../bsdlib.o:bsdlib.cc:(.eh_frame+0x12): undefined reference to
>`___gxx_personality_v0' [...]
>
>After a bit of digging I found that the -fno-rtti -fno-exceptions flags
>are missing when building the C++ source files.
Thanks for tracking this down. That was part of an overaggressive
purging of Makefile.common. I don't know why I wouldn't be seeing this
when building with nonstandard library locations though.
>When building cygserver stuff, the flags -mno-use-libstdc-wrappers
>-fno-rtti -fno-exceptions are missing, too.
-fno-rtti and -fno-exceptions are expected given the above. AFAICT,
cygserver hasn't ever set -mno-use-libstdc-wrappers.
>In utils, I get an interesting error when building cygcheck:
>
> In file included from .../cygcheck.cc:13:0:
> .../newlib/libc/include/stdio.h:35:20: fatal error: stddef.h: No such file
> or directory
>
>Newlib? For a Mingw application? The compiler instruction actually
>contains the following paths:
>
> -I${srcdir}/winsup/cygwin \
> -isystem /usr/i686-pc-cygwin/sys-root/usr/include/w32api \
> -isystem ${srcdir}/winsup/cygwin/include \
> -isystem ${srcdir}-pc-cygwin/newlib/targ-include \
> -isystem ${srcdir}/newlib/libc/include
>
>None of them should be used when building with the Mingw compiler.
Actually, cygcheck.o and path.o need newlib since cygcheck includes
mntent.h and mntent.h uses paths.h which comes from newlib. It
shouldn't be trying to get stdio.h from newlib though. That's fixed.
>Btw., why did you remove $(CFLAGS) from the definition of MINGW_CXX?
>I added it just a couple of days ago explicitely to be able to build
>the utils manually with different optimizing settings:
I didn't know it was a recent change but, as I mentioned in my initial
notes, I decoupled CFLAGS and CXXFLAGS when I got rid of our nonstandard
checks for the C compiler. The change was inadvertent at first but then
I realized that everywhere else in the world those two flags mean two
different things and are meant to control c/c++ compilation. The fact
that they don't in Cygwin is just because I was either too lazy or too
ignorant when I first set that up.
However, I did add code to Makefile.common so that if you say:
"make CFLAGS=-g" it will remove any optimization from CXXFLAGS as
well.
I have nearly everything working again but I'm surprised to find out
that I can't build dump_setup.o with FC16 installed mingw compilers due
to complaints about missing definitions for:
NT_SUCCESS
OBJ_CASE_INSENSITIVE
InitializeObjectAttributes
I can't build strace.o because of missing definitions for:
ProcessDebugFlags
NtSetInformationProcess
These are not pulled in by winternl.h in the
mingw32-headers-2.0.999-0.5.trunk.20120224.fc17.noarch package but
they do seem to be handled correctly in the versions I downloaded from
the Cygwin repo.
What version of mingw headers are you running that enables you to
compile these packages? I can't get them to build even in an unpatched
sandbox.
Btw, I believe that these will probably compile correctly if I use the
w32api headers from Yaakov's cygwin cross gcc packages (which was why
things seemed to work for me before) but that's clearly not the right
way to deal with this issue.
cgf
