Mail Archives: cygwin/2006/03/23/21:32:26
On Thu, 2006-03-23 at 06:02 -0800, Gary Zablackis wrote:
> --- skaller <skaller AT users DOT sourceforge DOT net> wrote:
>
> > On Wed, 2006-03-22 at 03:35 +0100, Bernhard Loos
> > wrote:
> >
> > > If the C++library declares its calls as 'extern
> > "C"' (as it is done in the example),
> > > AFAIK there shouldn't be any problem.
> >
> > Doesn't matter what you think you know -- it's not a
> > permitted thing
> > to do, you never know what implementors are going to
> > change.
> >
>
> Who forbad it?
The C++ Standard plus a whole lot of reasons
related to startup and termination: C++ operates in a different
environment to C: constructors, extra I/O objects, exception
handling, etc etc.
Of course C++ doesn't support dynamic loading anyhow, so it
would better to say 'it is wise to compile your mainline
as C++ if you use C++ libraries, so as to avoid potential
problems'.
> A dll is just code which can be called
> from any language as long as the interface rules are
> followed by compilers, linkers and coders.
And part of those rules includes the establishment of certain
environmental considerations.
on a typical platform there is a 'stub' startup object
file usually called 'crt0' or something which actually
calls the user mainline. C++ is free to use a different
startup object. Whether GNU uses it or not I don't know.
C++ basically has to establish a workable C environment,
but C doesn't have to establish a workable C++ environment.
> Anyway, the problem illustrated by the test case
> occurs when a dll linked with -lstdc++ is dynamically
> linked (via dlopen()) by a program which has not
> previously initialized the standard library io
> functions.
Actually no, the problem is that the 1.5.19 Cygwin1.dll
is screwed up somehow entirely unrelated to dlopen(),
since I have plain old static linked C++ program
which also crashes on 1.5.19 but works fine on 1.5.18.
I have no idea what the problem is, since the program
is actually written in Felix and translated to C++.
Unfortunately it's a core tool without which nothing will
work (which is why it is statically linked).
The tool actually doing the translation works fine, however
it is generated by assembler. All the other programs loaded
as binary packages before upgrade also seem to work. Which is a bit
mysterious but suggests the problem is a mismatch at the
developer level, i.e. between C header files and libraries.
I could actually test that if I could figure out how to start
ssh daemon again -- by scp'ing the binaries from 1.5.18 to
1.5.19 environment and vice/versa to see what happens.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -