[1.7] Possible dynamic linker error

[Charles Plager]

David Korn wrote:
>> - I ran rebaseall on cygwin and all of the dlls in questions.  It still
>> crashes, but now crashes somewhere else.
> 
>   Ah!  Reinstall your libstdc++ dll.  Yaakov spotted that the 4.3.4-1
> libstdc++ dll isn't rebaseable, as it turns out there's a bug in LD(*).
> 
>   I'm just doing final testing on a new release to fix the problem, but until
> that's out, the current libstdc++ dll will have to be reinstalled if it gets
> rebased.

O.k.  Copying 'cygstdc++-6.dll' did "restore" the original problem (as 
well as allowed the "statically-linked" executable to work again).

>> libraries were compiled by me on the same machine using gcc4.3.4).  When
>> looking at the problem using GDB, it says it is now going to jump to
>> subroutine A (finishConstruction()), but instead jumps to subroutine B
>> (edm::ValueMap<double>::operator+=).
> 
>   This could be just the ordinary sort of thing that goes on when you compile
> with optimisation (and hence inlining) turned on.  It looks from the earlier
> lines like it's just constructed a std::map as part of the PluginFactory or
> PluginFactoryBase constructors, so if that edm::ValueMap is a derivation of
> std::map it might well be that finishConstruction() is correctly invoking the
> += operator to append an item, and gdb is showing you the source of the
> inlined operator function.
> 
>   So I think first thing you need to do is figure out if maybe it's actually
> going the right code path, and has gotten something wrong with the value of j.
>  Check the value of $eip before and after that final step command and find out
> exactly where you're running.


 From my friend Chris:
> 	The edm::ValueMap is not a 'derivation' of std::map, in fact it 
> doesn't even use it.  Also, finishConstruction() is not inlined [since 
> it is defined in a .cc file] and therefore has to be called directly.

So between the fact that the statically linked executable works and the 
above, it really does look like the code is jumping to the wrong 
function.  I'm attaching the another gdb session where I look at $eip 
before and after to see if that provides any clues.  Do you have any 
other ideas?  Is the dll simply too big?

	Thanks,
	  Charles

* "statically linked" just means that we don't dynamically link to the 
400 Mb dll, but rather compile in those .o files.  We still statically 
link to the rest of the libraries shown in:
http://cygwin.com/ml/cygwin/2009-12/msg00275.html

p.s. Since I'm not on the mailing list, is there a way to have a 
particular message sent to me so I can respond to it and not screw up 
the threading?


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdb.out
URL: <http://cygwin.com/pipermail/cygwin/attachments/20091211/3f9da0a4/attachment.ksh>
-------------- next part --------------
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple