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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I'll try to get to a test build with the instructions tomorrow or 
Monday.   Thanks!

--
Kevin

On 17 November 2008 at 7:16, Pete Stieber <pst...@gm...> wrote:

> DM> (should this be /usr/local/Jazz++/share/Jazz++/HelpFiles ??)....
> 
> Kevin, since you have Linux packaging experience, where are help files 
> typically installed?

$prefix/share/<appname>/...  Is common, like what's above.

BTW, I've got wx built using the web instructions.  I'm still
working on the rest.

Thanks....

--
Kevin

DM = D.B. Moore
DM>>> (should this be /usr/local/Jazz++/share/Jazz++/HelpFiles ??)....

PS = Pete Stieber
PS>> Kevin, since you have Linux packaging experience,
PS>> where are help files typically installed?

KC = Kevin Cosgrove
KC> $prefix/share/<appname>/...  Is common, like what's above.

I just made this change to both the automake input files (Makefile.am) 
and the code itself.

You can clean-up, update, rebuild and reinstall Jazz++ to test.

Maybe this will fix Donald's "can't automatically find the help files" 
problem.

Testing always welcome.

Thanks,
Pete

On 15 November 2008 at 16:56, Pete Stieber <pst...@gm...> wrote:

> After I posted the new build instructions, I attempted to test them by 
> actually trying them.  wxWidgets and tex2rtf went off without a hitch. 
> Jazz++ was another matter on Linux.

I've got a clean build.

> After I installed Jazz++ as root under /usr/local/Jazz++, the fun began, 
> but I think I've worked through most of the issues.  Please attempt this 
> to help me test.  When you do, make sure you erase the .Jazz++ 
> configuration file that is in your home directory.

I don't find a config file there.  Hmmm.  Maybe because that's my
JAZZ environment variable is set to /usr/local/jazz?  This goes
way, way back in time.  I'm unsetting that variable.

> The first time you run the code, a directory with the same name
> should be created, and configuration files will be copied to
> this directory.

Trying to run jazz I get X window errors, which I'm nearly
certain are due to my present environment and have nothing to do
with jazz.  I get the same errors this morning with other apps,
which I didn't get last Friday.  Grr.  I'm dropping the log from
starting up jazz below my sig, just for fun.

I'll try to run jazz again when I'm in a sane environment.

> Maybe someday I'll actually get to work on the inner workings of Jazz++ ;-)

I hope so.  That's where the fun is, right?

--
Kevin

(jazz:12682): Gdk-WARNING **: Connection to display localhost:12.0 appears to be untrusted. Pointer and keyboard grabs and inter-client communication may not work as expected.
JZProject::ReadConfiguration() JazzCfgFile:
  "/home/kevinc/.Jazz++/jazz.cfg"
JZConfiguration::LoadConfig:
  "/home/kevinc/.Jazz++/jazz.cfg"
Include synthesizer configuration file "gs.jzi"
FindFile: Immediate hit on file "gs.jzi"
Include file "gsdrmset.jzi"
FindFile: Immediate hit on file "gsdrmset.jzi"
Include file "gmdrmnam.jzi"
FindFile: Immediate hit on file "gmdrmnam.jzi"
Include file "gsvoices.jzi"
FindFile: Immediate hit on file "gsvoices.jzi"
Include file "ctrlnam.jzi"
FindFile: Immediate hit on file "ctrlnam.jzi"
INFO: Created client:port = 128:0
INFO: Input device count: 1
Input Devices
Midi Through Midi Through Port-0 = 14:0
INFO: Output device count: 1
Output Devices
Midi Through Midi Through Port-0 = 14:0
INFO: input device is -1, so selecting one.
The program 'jazz' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 74 error_code 5 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

KC = Kevin Cosgrove
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 apps,
KC> which I didn't get last Friday.  Grr.  I'm
KC> dropping the log from starting up jazz below my
KC> sig, just for fun.

<snip>

KC> (jazz:12682): Gdk-WARNING **: Connection to display
KC> localhost:12.0 appears to be untrusted. Pointer and
KC> keyboard grabs and inter-client communication may not
KC> work as expected.

Are you running locally?  I've seen this type of thing when running an X 
application over ssh from another machine.

What do you get when you type...

$ set | grep DISPLAY

from a terminal application (if you can get one started ;-) )?

Pete

On 17 November 2008 at 11:04, Pete Stieber <pst...@gm...> wrote:

> KC> (jazz:12682): Gdk-WARNING **: Connection to display
> KC> localhost:12.0 appears to be untrusted. Pointer and
> KC> keyboard grabs and inter-client communication may not
> KC> work as expected.
> 
> Are you running locally?  I've seen this type of thing when running an X 
> application over ssh from another machine.
> 
> What do you get when you type...
> 
> $ set | grep DISPLAY

I was running SSH at the time.

> from a terminal application (if you can get one started ;-) )?

On my local console, in an xterm I run jazz and get to select two 
MIDI ports from a list.  Then I get a core dump.  This is what I get 
in the xterm up to that point:

JZProject::ReadConfiguration() JazzCfgFile:
  "/home/kevinc/.Jazz++/jazz.cfg"
JZConfiguration::LoadConfig:
  "/home/kevinc/.Jazz++/jazz.cfg"
Include synthesizer configuration file "gs.jzi"
FindFile: Immediate hit on file "gs.jzi"
Include file "gsdrmset.jzi"
FindFile: Immediate hit on file "gsdrmset.jzi"
Include file "gmdrmnam.jzi"
FindFile: Immediate hit on file "gmdrmnam.jzi"
Include file "gsvoices.jzi"
FindFile: Immediate hit on file "gsvoices.jzi"
Include file "ctrlnam.jzi"
FindFile: Immediate hit on file "ctrlnam.jzi"
INFO: Created client:port = 128:0
INFO: Input device count: 1
Input Devices
Midi Through Midi Through Port-0 = 14:0
INFO: Output device count: 1
Output Devices
Midi Through Midi Through Port-0 = 14:0
INFO: input device is -1, so selecting one.
INFO: Input device is: 0
INFO: Output device is -1, so selecting one.

(jazz:14539): Gtk-WARNING **: Theme file for default has no name

(jazz:14539): Gtk-WARNING **: Theme file for default has no directories

Floating exception (core dumped) 

I could trace the core, if you give me instructions on what you'd 
want.  I could also run jazz in gdb or something, and let you know 
what happens.

Cheers....

--
Kevin

KS = Kevin Cosgrove
KC>>> (jazz:12682): Gdk-WARNING **: Connection to display
KC>>> localhost:12.0 appears to be untrusted. Pointer and
KC>>> keyboard grabs and inter-client communication may not
KC>>> work as expected.

PS = Pete Stieber
PS>> Are you running locally?  I've seen this type of thing
PS>> when running an X application over ssh from another
PS>> machine.
PS>>
PS>> What do you get when you type...
PS>>
PS>> $ set | grep DISPLAY

KC> I was running SSH at the time.

Did you use

$ ssh -Y ...

to connect?  I doubt jazz will work if not running locally.

KC> On my local console, in an xterm I run jazz
KC> and get to select two MIDI ports from a list.
KC> Then I get a core dump.  This is what I get
KC> in the xterm up to that point:
KC>
KC> JZProject::ReadConfiguration() JazzCfgFile:
KC>   "/home/kevinc/.Jazz++/jazz.cfg"
KC> JZConfiguration::LoadConfig:
KC>   "/home/kevinc/.Jazz++/jazz.cfg"
KC> Include synthesizer configuration file "gs.jzi"
KC> FindFile: Immediate hit on file "gs.jzi"
KC> Include file "gsdrmset.jzi"
KC> FindFile: Immediate hit on file "gsdrmset.jzi"
KC> Include file "gmdrmnam.jzi"
KC> FindFile: Immediate hit on file "gmdrmnam.jzi"
KC> Include file "gsvoices.jzi"
KC> FindFile: Immediate hit on file "gsvoices.jzi"
KC> Include file "ctrlnam.jzi"
KC> FindFile: Immediate hit on file "ctrlnam.jzi"
KC> INFO: Created client:port = 128:0
KC> INFO: Input device count: 1
KC> Input Devices
KC> Midi Through Midi Through Port-0 = 14:0
KC> INFO: Output device count: 1
KC> Output Devices
KC> Midi Through Midi Through Port-0 = 14:0
KC> INFO: input device is -1, so selecting one.
KC> INFO: Input device is: 0
KC> INFO: Output device is -1, so selecting one.
KC>
KC> (jazz:14539): Gtk-WARNING **: Theme file for default has no name
KC>
KC>
KC> (jazz:14539): Gtk-WARNING **: Theme file for default has no directories
KC>
KC> Floating exception (core dumped)
KC>
KC> I could trace the core, if you give me
KC> instructions on what you'd want.  I could
KC> also run jazz in gdb or something, and let
KC> you know what happens.

Maybe

$ gdb jazz
(gdb) run
(gdb) bt

and send some of the resulting text.  This gets difficult when I can't 
reproduce the problem.

Pete

On 17 November 2008 at 11:55, Pete Stieber <pst...@gm...> wrote:

> KC> I was running SSH at the time.
> 
> Did you use
> 
> $ ssh -Y ...
> 
> to connect?  I doubt jazz will work if not running locally.

ssh -f to connect.  Jazz ran like that for me before, with previous 
threads of what the three of us have been playing with on & off for 
the last many months.  I'm sure that problem is on my end, and I can 
point to a config change last Friday (out of my control) which likely
caused the issue.  It's being worked on.

I'll get the backtrace from gdb later.

Thanks....

--
Kevin

On 17 November 2008 at 11:55, Pete Stieber <pst...@gm...> wrote:

> Maybe
> 
> $ gdb jazz

GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...Using host libthread_db library "/lib/i686/libthread_db.so.1".

> (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

Program exited with code 0177.
Current language:  auto; currently c

[kevinc@joseph-src #1613] printenv LD_LIBRARY_PATH
/usr/local/src/INCOMING/BUILD/Jazz/wx289/lib

[kevinc@joseph-src #1617] ll $LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0
lrwxrwxrwx 1 kevinc kevinc 33 Nov 16 20:32 /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0 -> libwx_gtk2d_richtext-2.8.so.0.5.0

[kevinc@joseph-src #1618] ll $LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0.5.0  
-rwxr-xr-x 1 kevinc kevinc 5154209 Nov 16 20:32 /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0.5.0

It looks like the library isn't getting picked up, but I'm not sure 
why.  Does Jazz look at LD_LIBRARY_PATH?  Or, do I need some other 
environment variable?  Or?

Thanks....

> (gdb) bt
> 
> and send some of the resulting text.  This gets difficult when I can't 
> reproduce the problem.

--
Kevin

KC> Starting program: 
/home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz
KC> Reading symbols from shared object read from target memory...done.
KC> Loaded system supplied DSO at 0xffffe000
KC> /home/local/src/INCOMING/BUILD/Jazz/JazzBuild/src/jazz:
KC> error while loading shared libraries: libwx_gtk2d_richtext-2.8.so.0:
KC> cannot open shared object file: No such file or directory
KC>
KC> [kevinc@joseph-src #1613] printenv LD_LIBRARY_PATH
KC> /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib
KC>
KC> [kevinc@joseph-src #1617] ll 
$LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0
KC> lrwxrwxrwx 1 kevinc kevinc 33 Nov 16 20:32 
/usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0 
-> libwx_gtk2d_richtext-2.8.so.0.5.0
KC>
KC> [kevinc@joseph-src #1618] ll 
$LD_LIBRARY_PATH/libwx_gtk2d_richtext-2.8.so.0.5.0
KC> -rwxr-xr-x 1 kevinc kevinc 5154209 Nov 16 20:32 
/usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0.5.0
KC>
KC> It looks like the library isn't getting picked up, but I'm not sure
KC> why.  Does Jazz look at LD_LIBRARY_PATH?  Or, do I need some other
KC> environment variable?  Or?

Here's a good description of how shared libraries are found...

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

Try

$ export LD_DEBUG=files

and run jazz.  This will turn on a bunch of debug output.  Does it tell 
you anything useful?

Have you built tex2rtf recently?

When did you build Jazz++?

I ask because part of the build process runs tex2rtf to generate help. 
If you built tex2rtf recently, it requites the same wxWidgets shared 
objects (well actually release versions) and should have had problems too.

Pete

On 17 November 2008 at 13:03, Pete Stieber <pst...@gm...> wrote:

> Have you built tex2rtf recently?

Everything is a fresh build.  I built wxWidgets first, then
tex2rtf, then jazz, all of that after you advertised your most
recent instruction set on the webpage.

> When did you build Jazz++?
> 
> I ask because part of the build process runs tex2rtf to generate help. 
> If you built tex2rtf recently, it requites the same wxWidgets shared 
> objects (well actually release versions) and should have had problems too.

I had a PATH issue on the first attempt, but I fixed that and all
the builds finished without errors.

Thanks....

--
Kevin

PS>> Have you built tex2rtf recently?

KC> Everything is a fresh build.  I built wxWidgets
KC> first, then tex2rtf, then jazz, all of that after
KC> you advertised your most recent instruction set
KC> on the webpage.

This is the correct order.

PS>> When did you build Jazz++?
PS>>
PS>> I ask because part of the build process runs
PS>> tex2rtf to generate help.  If you built tex2rtf
PS>> recently, it requites the same wxWidgets shared
PS>> objects (well actually release versions) and
PS>> should have had problems too.

KC> I had a PATH issue on the first attempt, but I
KC> fixed that and all the builds finished without
KC> errors.

Did you try the "export LD_DEBUG=files" test?

What to see if you type

$ tex2rtf

in a terminal?  Should be...

<tex2rtf output>
Tex2RTF: input or output file is missing.
Tex2RTF version 2.88
Usage: tex2rtf [input] [output] [switches]

where valid switches are
     -bufsize <size in K>
     -charset <pc | pca | ansi | mac> (default ansi)
     -twice
     -sync
     -checkcurlybraces
     -checksyntax
     -version
     -macros <filename>
     -winhelp
     -rtf
     -html
     -xlp

</tex2rtf output>

Sorry about all of the problems,
Pete

On 17 November 2008 at 14:02, Pete Stieber <pst...@gm...> wrote:

> Did you try the "export LD_DEBUG=files" test?

Got >28k lines of output.  Attached.

> What to see if you type
> 
> $ tex2rtf
> in a terminal?  Should be...

I got what's below.

> <tex2rtf output>
> Tex2RTF: input or output file is missing.
> Tex2RTF version 2.88
> Usage: tex2rtf [input] [output] [switches]
> 
> where valid switches are
>      -bufsize <size in K>
>      -charset <pc | pca | ansi | mac> (default ansi)
>      -twice
>      -sync
>      -checkcurlybraces
>      -checksyntax
>      -version
>      -macros <filename>
>      -winhelp
>      -rtf
>      -html
>      -xlp
> 
> </tex2rtf output>

Cheers....

--
Kevin

> To: jazzplusplus-devel
> Date: Mon, 17 Nov 2008 16:43:49 -0800
> From: kevinc
> Subject: Re: [jazzplusplus-devel] New web build instructions and a better	Linux install
> 
> 
> On 17 November 2008 at 14:02, Pete Stieber <pstieber> wrote:
> 
> > Did you try the "export LD_DEBUG=files" test?
> 
> Got >28k lines of output.  Attached.
> 
> > What to see if you type
> > 
> > $ tex2rtf
> > in a terminal?  Should be...
> 
> I got what's below.
> 
> > <tex2rtf output>
> > Tex2RTF: input or output file is missing.
> > Tex2RTF version 2.88
> > Usage: tex2rtf [input] [output] [switches]
> > 
> > where valid switches are
> >      -bufsize <size in K>
> >      -charset <pc | pca | ansi | mac> (default ansi)
> >      -twice
> >      -sync
> >      -checkcurlybraces
> >      -checksyntax
> >      -version
> >      -macros <filename>
> >      -winhelp
> >      -rtf
> >      -html
> >      -xlp
> > 
> > </tex2rtf output>
> 
> Cheers....
> 
> 
> --
> Kevin
> 

Woke up this morning and saw all recent chatter - throw my 2cents in here as well ;

It does work over ssh - I know, it's how I routinely check builds on the Deb systems
here -- of course, you need set DISPLAY to the local (connecting host) vidport,
and you have to allow the remote host connection on the local machine (xhost +
remote_ip_addr)....works just fine.

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

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

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

When we add  ;
export LD_LIBRARY_PATH=/usr/local/wx289/lib:$LD_LIBRARY_PATH

..to the user's .bash_profile, the variable set will appear as ;

LD_LIBRARY_PATH="/usr/local/wx289/lib:"

...with the trailing colon. AFAIK, this shouldn't be a problem...it should just delimit
the string and ignore the nothingness thereafter...at least, that is what I observe
in practise here -- it just looks a bit out of place. We probably have to do it as it
stands though, 'just in case' the user already has LD_LIBRARY_PATH set.....

Now I'm off to update my jazz tree and do it all again to check latest changes...

Regards,

Don

_________________________________________________________________
Take a summer road trip with Windows Live Hotmail. Multiple prizes and the ultimate dream beach house!
http://www.ninemsn.com.au/hotmailroadtrip
On 17 November 2008 at 14:02, Pete Stieber <pst...@gm...> wrote:

> Did you try the "export LD_DEBUG=files" test?

Not yet.  I'm at the wrong system.  I tried it from the right
system when I was home at lunch.  I'll try again later, probably
after my kids' go to bed.

> Sorry about all of the problems,

No problem at all.  That's what debugging is all about, right?
Thanks for all of the help!

--
Kevin

On 18 November 2008 at 1:45, "D.B. Moore" <db...@ho...> wrote:

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

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

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

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

> Also...and I don't think this is a problem but it gets a
> mention...on the Deb systems here (and my construct), the
> variable LD_LIBRARY_PATH is no longer system set -- it is
> deduced from /etc/ld.co.conf in practise, if LD_LIBRARY_PATH
> is unset. (actually, it falls through to /etc/ld.so.conf if
> LD_LIBRARY_PATH is unset, but if LD_LIBRARY_PATH is set it
> takes precedence..)
> 
> When we add export
> LD_LIBRARY_PATH=/usr/local/wx289/lib:$LD_LIBRARY_PATH
> 
> ..to the user's .bash_profile, the variable set will appear as 
> 
> LD_LIBRARY_PATH="/usr/local/wx289/lib:"
> 
> ...with the trailing colon. AFAIK, this shouldn't be a
> problem...it should just delimit the string and ignore the
> nothingness thereafter...at least, that is what I observe in
> practise here -- it just looks a bit out of place. We probably
> have to do it as it stands though, 'just in case' the user
> already has LD_LIBRARY_PATH set.....

Your description of LD_LIBRARY_PATH matches my experience.

I believe that my libraries are found correctly:

ldd bin/jazz

	linux-gate.so.1 =>  (0xffffe000)
	libwx_gtk2d_richtext-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_richtext-2.8.so.0 (0xb7e03000)
	libwx_gtk2d_aui-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_aui-2.8.so.0 (0xb7d80000)
	libwx_gtk2d_xrc-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_xrc-2.8.so.0 (0xb7cda000)
	libwx_gtk2d_qa-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_qa-2.8.so.0 (0xb7cb4000)
	libwx_gtk2d_html-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_html-2.8.so.0 (0xb7beb000)
	libwx_gtk2d_adv-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_adv-2.8.so.0 (0xb7af1000)
	libwx_gtk2d_core-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2d_core-2.8.so.0 (0xb76f0000)
	libwx_based_xml-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_based_xml-2.8.so.0 (0xb76e4000)
	libwx_based_net-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_based_net-2.8.so.0 (0xb769e000)
	libwx_based-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_based-2.8.so.0 (0xb74be000)
	libasound.so.2 => /usr/lib/libasound.so.2 (0xb73c9000)
	libdl.so.2 => /lib/libdl.so.2 (0xb73c5000)
	libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb73b2000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb72cd000)
	libm.so.6 => /lib/i686/libm.so.6 (0xb72a8000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb729c000)
	libc.so.6 => /lib/i686/libc.so.6 (0xb716f000)
	libz.so.1 => /lib/libz.so.1 (0xb715c000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6dce000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6d41000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6d25000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6d0c000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6cce000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6c90000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6c8c000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6c87000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6beb000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6be7000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6be2000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0xb6bd9000)
	libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6bb3000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6b90000)
	libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6b3d000)
	libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6b1a000)
	/lib/ld-linux.so.2 (0xb7f17000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6b11000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb6a12000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb69a2000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6974000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0xb6965000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb695c000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0xb6954000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6950000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6945000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6940000)
	librt.so.1 => /lib/i686/librt.so.1 (0xb6937000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0xb691e000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb68ef000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6881000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb687e000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6878000)
	libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb674b000)

ldd bin/tex2rtf

	linux-gate.so.1 =>  (0xffffe000)
	libwx_gtk2_richtext-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_richtext-2.8.so.0 (0xb7dfa000)
	libwx_gtk2_aui-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_aui-2.8.so.0 (0xb7d8f000)
	libwx_gtk2_xrc-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_xrc-2.8.so.0 (0xb7ce5000)
	libwx_gtk2_qa-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_qa-2.8.so.0 (0xb7cc4000)
	libwx_gtk2_html-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_html-2.8.so.0 (0xb7c11000)
	libwx_gtk2_adv-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_adv-2.8.so.0 (0xb7b44000)
	libwx_gtk2_core-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_gtk2_core-2.8.so.0 (0xb77e1000)
	libwx_base_xml-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_base_xml-2.8.so.0 (0xb77d5000)
	libwx_base_net-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_base_net-2.8.so.0 (0xb77a4000)
	libwx_base-2.8.so.0 => /usr/local/src/INCOMING/BUILD/Jazz/wx289/lib/libwx_base-2.8.so.0 (0xb7649000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7545000)
	libm.so.6 => /lib/i686/libm.so.6 (0xb7520000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7515000)
	libpthread.so.0 => /lib/i686/libpthread.so.0 (0xb7502000)
	libc.so.6 => /lib/i686/libc.so.6 (0xb73d5000)
	libz.so.1 => /lib/libz.so.1 (0xb73c1000)
	libdl.so.2 => /lib/libdl.so.2 (0xb73bd000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb702f000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6fa2000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f86000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6f6e000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6f2f000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6ef1000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6eed000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6ee8000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6e4c000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6e49000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6e43000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0xb6e3a000)
	libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6e14000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6df1000)
	libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6d9e000)
	libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6d7b000)
	/lib/ld-linux.so.2 (0xb7efb000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6d72000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb6c73000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6c04000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6bd5000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0xb6bc6000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6bbd000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0xb6bb5000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6bb1000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6ba7000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6ba1000)
	librt.so.1 => /lib/i686/librt.so.1 (0xb6b98000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0xb6b7f000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6b50000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6ae3000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb6adf000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6ad9000)
	libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb69ac000)

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

Thanks....

--
Kevin

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

On 19 November 2008 at 10:35, Pete Stieber <pst...@gm...> wrote:

> The machine I had success with was Mandrive 2008.0.

Good news for me!

> 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?

No, that was a new security layer at work, which placed a new demand
on my SSH config.  It's all better now.

> 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 :-(

Yup.  I think I need to build on something a little more controlled 
than what I've got.  I didn't do anything other than Mandriva 
updates, but I did updates for years and I'm not certain what state 
it's in.  The newer versions of the distro seem to be better in a 
number of ways, including the update scenario.

Cheers....

--
Kevin