Re: [jazzplusplus-devel] New web build instructions and a better Linux install

[Pete S. <pst...@gm...>]

DM>> Regarding attachment log....it would appear not to be
DM>> jazz at all, but instead the interaction between
DM>> gtk_libs and glib_libs (more particularly here
DM>> librsvg/pixbuf and other related libs)....although
DM>> how this could happen on a mainstream distro
DM>> is a bit peculiar....have you upgraded any of these
DM>> related pkgs lately?

KC> I haven't updated anything on this system lately.
KC> It's Mandriva 2007.0 and out of it's end of update
KC> period.  Mandriva 2009.0 is recently out, and I just
KC> burned an install DVD a couple of days ago.  It
KC> looks like I get to play with that.  I also have a
KC> couple of laptops, one Mandriva 2008.0 and the other
KC> 2008.1.  I could try a build on those, but it'll
KC> be sloooooow.  The fastest of those machines is a PIII

The machine I had success with was Mandrive 2008.0.

DM>> FWIW, I -could- recreate this kind of error (I've
DM>> seen it before) by doing something like upgrading
DM>> the version of glib but not rebuilding (or upgrading)
DM>> gtk, or similarly not doing the same with librsvg
DM>> after a glib change (or anything else that is glib
DM>> dependent), but usually I see relocation errors,
DM>> not undefined_ref errors....so maybe your problem
DM>> is something different....like runtime linker
DM>> failing to load something...

KC> I've not had that happen when I build my own
KC> software.  And the log seems to say that it's
KC> finding everything.  Maybe I'm unclear
KC> on how that works?

DM>> Also...and I don't think this is a problem but it
DM>> gets a mention...on the Deb systems here (and my
DM>> construct), the variable LD_LIBRARY_PATH is no
DM>> longer system set -- it is deduced from
DM>> /etc/ld.co.conf in practise, if LD_LIBRARY_PATH
DM>> is unset. (actually, it falls through to
DM>> /etc/ld.so.conf if LD_LIBRARY_PATH is unset, but
DM>> if LD_LIBRARY_PATH is set it takes precedence..)

This is explained in

http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html

Just search for LD_LIBRARY_PATH using your web browser.

DM>> When we add export
DM>> LD_LIBRARY_PATH=/usr/local/wx289/lib:$LD_LIBRARY_PATH
DM>>
DM>> ..to the user's .bash_profile, the variable set
DM>> will appear as
DM>>
DM>> LD_LIBRARY_PATH="/usr/local/wx289/lib:"
DM>>
DM>> ...with the trailing colon. AFAIK, this shouldn't
DM>> be a problem...it should just delimit the string
DM>> and ignore the nothingness thereafter...at least,
DM>> that is what I observe in practise here -- it just
DM>> looks a bit out of place. We probably have to do
DM>> it as it stands though, 'just in case' the user
DM>> already has LD_LIBRARY_PATH set.....

Exactly.  This isn't a problem.

KC> Your description of LD_LIBRARY_PATH matches my
KC> experience.
KC>
KC> I believe that my libraries are found correctly:
KC>
KC> ldd bin/jazz
KC>
KC> 	linux-gate.so.1 =>  (0xffffe000)
KC> 	libwx_gtk2d_richtext-2.8.so.0 => /usr/local/src/INCOMING/BUILD...

<snip>

KC> I don't doubt that there could be issues with
KC> compatibility between various versions of my
KC> shared object libraries.  I'll see what
KC> happens on a different version of Mandriva.

Kevin, a while ago you wrote...

KC> Trying to run jazz I get X window errors, which
KC> I'm nearly certain are due to my present
KC> environment and have nothing to do with jazz.
KC> I get the same errors this morning with other
KC> apps, which I didn't get last Friday.  Grr.

Are you still having problems with other apps?

Going back through this thread, I'm seeing different problems.  For 
instance, when you tried to use gdb...

<GDB session>
(gdb) run
Starting program: /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
/home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz: error while 
loading shared libraries: libwx_gtk2d_richtext-2.8.so.0: cannot open 
shared object file: No such file or directory

Gdb said the library file didn't exist, but it was in the correct 
location with respect to LD_LIBRARY_PATH.

Then you sent the result of setting LD_DEBUG=files.  This logged 
indicated libwx_gtk2d_richtext-2.8.so.0 was found.  I'm wondering what 
changed?

The final error in your log was a missing gconv_end function.  Googling 
for this function, it looks like it is in glibc...

http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_node/libc_101.html

This thread looks similar

https://helixcommunity.org/projects/player/forums/entry/124

Maybe there is a library configuration problem on your machine, but I 
guess you already knew that :-(

Pete