[ydl-gen] GLIBCXX_3.4.4

[Derick Centeno]

Hi Peter:
I'm not sure I will have addressed all the aspects of your concern but 
the information here is what I could ascertain regarding it.
One reference I acquired was a discussion regarding the same problem 
you reported posted here:

  http://blog.arabx.com.au/?p=109

The devil, as usual is in the details.  The links to the recommended 
websites don't work, although they once did.
The resource I used to get to the required source in question was:

http://libsigc.sourcforge.net/stable.shtml

That lead me into here:

http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.0/

Unfortunately, you should immediately become suspicious as the most 
recent date of this software ends in Dec 20, 2005.
Furthermore after you manage to untar and review the source it is then 
you will see that this software is intended to build and construct 
macros and other libraries which address conversion problems between 
Win32 based systems and modern 64bit and higher systems.  The question 
really should be why bother with 32bit systems when 64 bit are 
available?  In other words, you should be able to do without these 
libraries entirely which also explains why the recommended directories 
mentioned within the above referenced blog don't exist within the YDL 
environment -- they (the directories) have to be created, as do the 
32bit related macros.

Of course, there are uses for 32bit processing still, but using a 64bit 
system to do it is a waste of cycles.  It may be a better use of 
resources to relegate such need to a pc which is noncritical or doesn't 
matter if it slows down as it should be dedicated to transferring 32bit 
into 64bit data.  Meanwhile highlevel processing requiring 64bit and 
higher receive the output from it's slower and ever decreasingly 
efficient partner without slowing downing critical jobs.

Best wishes...

On May 20, 2006, at 5:40 PM, Peter Seebach wrote:

> I have an application (binary only, for good reasons I'm afraid) which 
> won't
> run on YDL 4.1 because it can't find the symbol "GLIBCXX_3.4.4" in
> the libstdc++ installed on my system.
>
> This appears to indicate that libstdc++ was built with Something Other 
> Than
> gcc 3.4.4, but "gcc -v" says it's 3.4.4.
>
> What should I do?  Load source and rebuild libstdc++?  Would that 
> matter?
> Would it break other things?
>
> To forestall the obvious question, yes I have thought about trying to 
> rebuild
> the app, no I can't, and yes this is entirely reasonable in context.  
> The rest
> is a haze of NDAs and megacorps.  The application worked fine on 
> Fedora Core
> 4; I just wanted to be a step or so closer to support for the Quad G5 
> I want
> to be running this on if the fans are ever fixed.
>
> -s
> _______________________________________________
> yellowdog-general mailing list
> yellowdog-general at lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
> HINT: to Google archives, try  '<keywords> site:terrasoftsolutions.com'
>