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
[email protected]
http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
HINT: to Google archives, try '<keywords> site:terrasoftsolutions.com'
_______________________________________________
yellowdog-general mailing list
[email protected]
http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
HINT: to Google archives, try '<keywords> site:terrasoftsolutions.com'
