Hi, I can see from the backtrace that it is not a bug, but an
installation problem. There is no value defined for tcp_port_range,
which can't happen if the installation is correct and if the gconf
test was passed successfully.

Well, the gconf test was passed successfully; this is a recent CVS
build.  Perhaps it's a problem with a non-standard configure prefix?

./autogen.sh --prefix=/usr/local/gnome2 && make && make install

Further information that I just noticed:  when it starts up the
following message is printed to stderr: 
It appears that you do not have gnomemeeting.server installed in a
valid location. Factory mode disabled.

This I think further points to a problem with using a non-standard
configure prefix.  There is probably a hardcoded directory somewhere
that's causing this problem.

Not reopening since I don't want to step on your toes but I do think
that this is a real bug.

I've used jhbuild during several months without any problem and I know
CVS testers who are using garnome in another prefix too. 

Can you test the value of /apps/gnomemeeting/ports/tcp_port_range with
the gconftool-2 command compiled in your jhbuild environment? 

Also make sure that GnomeMeeting has been linked with the correct
gconf libraries (ie the one in your jhbuild environment).

There is something wrong related to gconf schemas installation, but
not to GnomeMeeting, I'm 99.99% sure, but I could be wrong, there
could still be something broken in the Makefiles.

I also have the feeling that you should have used
--sysconfdir=/usr/local/gnome2/etc/, but I'm not sure.

Finally, notice you can play with gnomemeeting-config-tool.
Also, GnomeMeeting is also using :
gconftool-2 --get-default-source to determine where to install gconf
schemas.

If you executed autogen.sh with jhbuild variables unloaded, it
probably used your standard gconftool-2 instead of the jhbuild one.

Good luck, keep me updated about this.

$ gconftool-2 --get /apps/gnomemeeting/ports/tcp_port_range
30000:30010

$ gconftool-2 --get-default-source
xml::/usr/local/gnome2/etc/gconf/gconf.xml.defaults

it looks like somehow gnomemeeting is being linked to the wrong gconf
libraries.  When I set LDFLAGS to -L/usr/local/gnome2/lib when
configuring it linked against the correct gconf library.  Not sure why
I would have needed to do a manual override like that; jhbuild is
supposed to take care of it.

Before doing that, when linking it had -L/usr/local/gnome2/lib in the
command line but inexplicably had -L/usr/lib before it.  I would guess
this was caused because some of the libraries like pth and openldap
are in /usr/lib and the configure script was getting confused.  It may
pay off to reorder how that command line is built so that gnome
libraries are done first.

However, even after fixing this problem, I still get the same crash on
startup (with the same null value for tcp_port_range).  At this point
I'm pretty baffled and I can't imagine what could be going wrong. 
It's linked against the right gconf library and the value seems to be
in there correctly.

Also now it seems able to find gnomemeeting.server but instead prints:
Failed to retrieve gnomemeeting server from activation server

Could this be a problem with bonobo activation?

Everything seems to be correct. I can't imagine either why it gets the
wrong gconf value. I suppose it is getting it from the wrong gconf
installation and not from the jhbuild installation. If you had time to
invest more time on this, I would be very grateful. Alternatively, you
can mail me privately and give me a private account on your computer
so that I can debug things remotely. Something is probably going wrong
at the compilation/linking stage, not really in the code (although I
will add a test for tcp_port_range)

"Could this be a problem with bonobo activation?"

Yes, the same kind of bug. Not really in the GnomeMeeting's code, but
something related to the installation. 

As an experiment, I apt-get installed gnomemeeting to see if that
would fix it; indeed it did, since apparently it was accessing the
systemwide schema

I was able to break it again by doing a apt-get remove --purge
gnomemeeting and then killing gconfd-2, so the problem is definitely
that it's trying to read the global schemas and not the jhbuild schemas.

It's also entirely possible that this problem is not unique to
gnomemeeting; it may well be the only core gnome program for which I
don't have the corresponding debian package already installed.

I'll email you with instructions on getting onto my computer if you're
still interested.

Just for the history of the bug:
I checked things on your machine. GConf schemas are installed at the
right place in the jhbuild environment. GnomeMeeting is compiled with
the right libraries, but it seems to link with libraries in /usr/lib
at runtime (following ldd). I don't know why though, but that's
something related to your particular setup.

I have investigated a bit more :
http://www.mail-archive.com/libtool@gnu.org/msg03901.html

That mail indicates the problem that appears on your computer: libtool
reorganizes the libraries directories and puts /usr/lib in the first
position whatever is the order of the directories given in the
command. As a result, it links with wrong libraries on your system.
This is due to SDL, returning /usr/lib as directory for its libraries.

I don't know how to fix that, I will have a deeper look at the problem
tomorrow and perhaps report a bug to libtool directly.

edit /usr/bin/sdl-config, remove the --rpath /usr/lib occurence from
the file, save, rebuild, run. it works...

The bug is related to the way RH9 ignores (wrongly) LD_LIBRARY_PATH
and sdl-config (wrongly) using a --rpath /usr/lib in its --libs
option... Kind of boring bug I must say.

I just want to add (for precision) that Debian acts the same way, and
that libtool wrongly reorders the -L order which causes the wrong libs
to be taken. I'll mark the bug as NOTGNOME as it is not directly
related to GM itself.

*** Bug 129111 has been marked as a duplicate of this bug. ***

*** Bug 131436 has been marked as a duplicate of this bug. ***