Mail Archives: djgpp/2002/11/11/10:30:24
Charles Wilkins <chas AT pcscs DOT com> wrote:
> My gut feeling, based on observation, tells me that a linux hosted
> libstdc++-v3 does not support djgppv2 as a target in its present form
> or if you are standing on the other side of the fence, the djgppv2
> target doesn't support the libstdc++-v3 linux host.
The problem is somewhere between the DJGPP runtime and the libstdc++.
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).
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++.
> It is only when linking against libstdcxx.a that the SIGSEGV occurs.
> So this tells me to look at all sources that are used to create
> libstdcxx.a.
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.
> 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 think I am going to go through the entire source tree for
> libstdc++-v3 and change all sources and their references to be
> compliant with 8.3 notation and see what happens. If I am lucky
> enough to get it to build, maybe it will fix this problem.
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.
> 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.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -