Mail Archives: djgpp/2002/11/11/11:30:13
>The problem is somewhere between the DJGPP runtime and the libstdc++.
I agree.
>But there is not really such a thing as a libstdc++ "hosted"
>somewhere. It's essentially just stored on Linux, but has no other
>links to that platform. The .a file should usually be identical to
>one built natively using DJGPP itself (or to the pre-built one).
In my case, the libstdc++.a is significantly larger than the native
build libstdc++.a
>I strongly suspect a linker script problem. E.g. the wrong libgcc
>might be used, either by the final installed toolchain or by the
>cross-build of libstdc++ itself. Or libgcc itself might be
>referencing the wrong libstdc++.
Very possible. I am doing my best to look into this now.
>Be sure to also consider the build setup files, i.e. Makefiles and
>linker scripts. Literally any file in the config/msdos subdirectory
>that the build process actually uses (or fails to use) could be the
>root of the problem.
I am backstepping all of the steps in my build proccess as well as
trying my best to consider all of the build setup files.
>> they use 'cxx' in their place. On the linux / libstdc++-v3 cross
>> compiler build, is it possible that the libstdc++ headers, which do in
>> fact use c++ in their name are causing the DOS exe crash due to the
>> 8.3 file limitation?
>
>No. Because none of those file names are even visible to the
>executable (they're buried in the debug info section). DOS doesn't
>have any way of knowing what the include file names were, at build
>time.
I found this out...
>Don't. A setup like this is almost completely unmaintainable. GCC
>maintainers know that, which is why the provided better methods, like
>the header file name mapping table. This maps a C++ header name to an
>actual, file name(s) representable on the host platform.
Too late... but it didnt fix the problem, so I know this wasn't it.
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0001f47f in std::ostream::sentry::sentry(std::ostream&) ()
>> (gdb)
>
>> not exactly a productive gdb session...
>
>You're supposed to ask gdb for whatever information about the crash.
>The most crucial command being "where", alias "backtrace" or "bt" for
>short.
I will do more with gdb when I feel more confident that I am not doing
something that is breaking the build setup files.
All of your suggestions are good ones.
Thank you.
Charles
- Raw text -