This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
2boxers <2boxers@comcast.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 ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |