X-Spam-Check-By: sourceware.org
Subject: Re: dlopen() bug
From: skaller <skaller AT users DOT sourceforge DOT net>
To: Gary Zablackis <gzabl AT yahoo DOT com>
Cc: Bernhard Loos <bernloos AT web DOT de>, cygwin AT cygwin DOT com
In-Reply-To: <20060323140259.33016.qmail@web53004.mail.yahoo.com>
References: <20060323140259 DOT 33016 DOT qmail AT web53004 DOT mail DOT yahoo DOT com>
Content-Type: text/plain
Date: Fri, 24 Mar 2006 13:32:06 +1100
Message-Id: <1143167526.16506.19.camel@rosella.wigram>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/