Package: gdc
Version: 4.1.2-13
The attached program segfaults. This affects e.g. torustrooper but I guess any
nontrivial D program is affected, too. Note that I'm running on PPC, which
might be an important part in this. When run, it displays
test1 foo
Segmentation fault
When run in gdb, the
Package: libstdc++6-4.1-dev
Version: 4.1.0-4
Hi!
I just noticed that the above package (and some others, see apt-cache showpkg
stl-manual) recommend the stl-manual. Now, the problem is that the STL is
obsolete. Back in the olden days, the STL was ported to C++ and presented to
the C++ committe
-manual package) for use with a halfway modern (>= 3.x)
GCC.
thanks
Ulrich Eckhardt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Friday 16 August 2002 21:47, Martin v. Loewis wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > How would this work? Would those using gcc-2.95 software have to set an
> > rpath or $LD_LIBRARY_PATH to take advantage of the compat libs? If so,
> > it hardly seems worth the effort; manual
eprocessor that cause
conflicts.
As I said, I don't have the standard at hand, so I can't tell which have to
be present and which not. Anyway, the asymmetric handling of short/int and
their unsigned equivalents suggests that there is something wrong.
cheers and regards
Ulrich Eckhardt
Package: libstdc++3-dbg
Version: 3.0.4-7
While trying to debug a program, I encountered some weird paths that
prevented me from taking advance of the debug-lib:
LD_PRELOAD=/usr/lib/libstdc++_debug/libstdc++3.so.3 gdb ./test
...
(gdb) step
178 in
/home/doko/packages/gcc/3.0/gcc-3.0-3.0.4ds3/
Package: libstdc++3-dbg
Version: 3.0.4-7
There is not a single note on how to use the lib for debugging, eg
setting:
LD_PRELOAD=/usr/lib/libstdc++_debug/libstdc++.so.3
before starting the program to be debugged or explicitly linking
with that lib (untested):
$(CXX) ... -l/usr/lib/libstdc++_de
7 matches
Mail list logo
