Mail Archives: djgpp-workers/2002/11/12/11:09:45
2boxers <2boxers AT comcast DOT net> wrote:
> > The other target headers should not
> > be seen by 'fixincludes', ie. the DJGPP2-headers are assumed to
> > already be 'suitable for GCC'... Although the header-fixing should
> > work, it is always safe to follow the old phrase: "Don't fix it,
> > if it ain't broken". Generally these vain fixes may not work but
> > instead may break the toolchain.
>
> I will try just sym linking limits.h into '$prefix/$target/sys-include' and
> not use the configure option --with-headers which copies them all and see if
> this makes a difference.
Hmmm, I saw you trying gcc-2.95.3 too and having problems with the
GCC's own 'stddef.h' and the 'fixed' DJGPP2-header 'stdio.h' :
>> In file included from
>> ../../../gcc-2.95.3-src/libiberty/../include/libiberty.h:127,
>> from ../../../gcc-2.95.3-src/libiberty/choose-temp.c:47:
>> /root/updates/gcc/djgpp/cross3/gcc-2.95.3-
>> obj/gcc/include/stddef.h:170:
>> warning: redefinition of `size_t'
>> /root/updates/gcc/djgpp/cross3/gcc-2.95.3-
>> obj/gcc/include/stdio.h:40:
>> warning: `size_t' previously declared here
This 'stdio.h' was taken from the target headers and fixed
for GCC... Only a warning, but 'size_t' was redefined to
something else and this should be checked... Normally the
'stdio.h' defines something like '__SIZE_T' and then the
'stddef.h' doesn't redefine 'size_t'... Maybe the 'fix'
spoiled the original 'stdio.h'. But in this case it maybe
is wrong to use the GCC's own 'stddef.h', 'stdarg.h' and
'varargs.h' because the DJGPP2-headers already have these.
>> /root/updates/gcc/djgpp/cross3/gcc-2.95.3-
>> obj/gcc/include/stddef.h:255:
>> conflicting types for `wchar_t'
>> /usr/local/compiler/cross3/djgpp/lib/gcc-lib/i686-pc-
>> msdosdjgpp/2.95.3
>> /../.. /../../i686-pc-msdosdjgpp/sys-include/stdlib.h:39:
>> previous declaration of `wchar_t'
The DJGPP2's own 'stdlib.h' clashes with the GCC's 'stddef.h',
so maybe it will be best to rename the three mentioned GCC's
own headers as 'stddef.h.gcc', 'stdarg.h.gcc' and 'varargs.h.gcc'
in the $build/gcc/include :
/root/updates/gcc/djgpp/cross3/gcc-2.95.3-obj/gcc/include
and so use only the original DJGPP2-headers in compiling...
So, when the target headers will not be fixed, the target headers
will remain non-compatible with the GCC's own headers, but although
these would be fixed, they still remain non-compatible... During
the GCC-part build there is the option:
'-isystem $prefix/$target/include' in the 'xgcc' command line to
cause the original target headers ('stddef.h'...'varargs.h') being
found first, but unfortunately not during the libraries-builds any
more... Anyway, if this is the case in the GCC-part and with
compiling 'libgcc.a'(s) there, maybe the same rule is suggested
with the 'libiberty' and 'libstdc++' too. So, disabling the GCC's
own headers sounds to be right... However I haven't seen any
authority ever telling what should be done when the target already
has the 'stddef.h', 'stdarg.h' and 'varargs.h'...
> It was not a stand alone paramater, but rather one of the parameters of
> the --with-libs option. The --with-libs accepts multiple directories. It
> should read:
>
> --with-libs=/usr/local/compiler/cross2/djgpp/lib
> /usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/lib
When more than one directory is there, they should be listed in
double quotes, ie.
--with-libs="/usr/local/compiler/cross2/djgpp/lib \
/usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/lib"
should be used. Maybe using a colon between then could also work
like in '--enable-languages=lang1,lang2,...', but the gcc-3.2
"GCC Install Manual" uses double quotes.
BTW, when talking about manuals and you have Linux in use with
its all tools, let's hope you have considered to use five minutes
more in the build and produce the GCC, binutils, GDB etc. manuals
too. My favourite is 'pdftex' for producing PDF-format manuals...
Of course the manual-production could be the 'stage-0' before the
'stage-1' in the GCC-build...
> > The current gcc-3.3 snapshots may/may not have this issue fixed,
> > anyhow I built the libstdc++-v3 there without this problem...
>
> Can you point me to the specific url or patches that you mentioned here?
> Are there gcc sources other than 3.2 that I should try that has these fixes
> merged? If so, specifically which versions?
The cross-GCC maillist archive should have the discussion related to
the 'sparc-sun-solaris2' or 'sparc-solaris2' (use these key words)...
The GCC-snapshots are available at (in mirrors too) :
ftp://sources.redhat.com/pub/gcc/snapshots
and the up-to-date weekly one should be 'gcc-3.3-20021111' from
yesterday... You could take diffs between the 'configure*' stuff
in it and in the gcc-3.2 sources... Maybe I have these things
already fixed in my 'gcc-3.2.1 (prerelease)' archive, this
'Really Soon Now' bugfix-release being as the snapshots before
the big gcc-3.3 diffs appeared... Why the 'gcc-3.2.1' bugfix-
release was never officially released is unknown... Anyway I
could extract these and email them...
> > A simple workaround could be to use the 'libstdcxx.a' from the
> > native gcc-3.2 distribution. Just as one can use prebuilt C-libs
> > (in 'djcrx203.zip'), one can use prebuilt C++ libs.
>
> Did you try this? I try it and it does not eliminate the SIGSEGV
> error... Thenagain, I haven't tried the other things you have
> suggested yet, either... so it is likely that something else is
> broken, but only shows itself when using C++ headers and linking to
> libstdc++.a.
The first question of course then is whether the native gcc-3.2
distribution works or not with C++ programs... One can take 'spare
parts' from it and test whether the engine now purrs... But not the
compiler binaries, only the libs...
Another possibility is the 'libgcc.a'... Experience with EMX and
maybe with DJGPP2 too, tells that sometimes the self-built 'libgcc.a'
doesn't work, while one taken from the distribution works. Getting
a working 'libgcc.a' then requires some odd methods in the native
environment, so it may be best to just take the 'native' libgcc.a'
and be happy. But generally producing a working 'libgcc.a' should
work also in the cross-build...
I tried another "Hello World" with a 'printf("Hi to all C lovers");'
before the 'cout', and the message from this appeared, so at least
some initializations in a C++ program works... Generally it would be
useful to have some test program which tests whether all the needed
'global constructors' etc. C++ initializations work as expected. The
situation where all C-programs work like a charm, but even the most
simplest C++ programs crash, is far from being rare, sigh...
It may be that some initializations (in '__main()' in libgcc.a')
will fail and only the first C++-things will get the program to
crash...
> I will post what I find.
That would be nice...
Cheers, Kai
- Raw text -