Re: [Denemo-devel] building on an old system again - error

[Bric]

On 06/10/2014 03:50 PM, Richard Shann wrote:
> On Tue, 2014-06-10 at 20:25 +0100, Richard Shann wrote:
> > On Tue, 2014-06-10 at 10:30 -0400, Bric wrote:
> > > On 06/10/2014 07:30 AM, Richard Shann wrote:
> > > > On Tue, 2014-06-10 at 07:16 -0400, Bric wrote:
> > > > > On 06/09/2014 11:51 PM, Bric wrote:
> > > > > > On 06/09/2014 11:16 PM, Bric wrote:
> > > > > > > On 06/09/2014 02:45 AM, Bric wrote:
> > > > > > > > Hi, guys!
> > > > > > > >
> > > > > > > > Here I go again, with an ancient Ubuntu 10.10 (I've upgraded my main
> > > > > > > > system to Ubuntu 14.04, but would like to build denemo on a
> > > > > > > > different, old system because it also has some apps built with
> > > > > > > > ancient code which is out of maintenance and not forward-compatible).
> > > > > > > >
> > > > > > > > So, I managed to ./configure the latest git on the old Ubuntu 10.10,
> > > > > > > > but "make" errors out, apparently because my libglib is too old.  Or
> > > > > > > > am I wrong?  Below is the error message.
> > > > > > > >
> > > > > > > > My libglib2.0-0 is version 2.26.1-0ubuntu1.  What are my options?
> > > > > > > > Thanks in advance.
> > > > > > > Anyone?  Am I correct in my assessment that this is a libglib version
> > > > > > > problem?
> > > > > > >
> > > > > > >
> > > > > > > What's the highest denemo version that works with libglib-2.26 ?
> > > > > > I think I just determined that the error starts with version
> > > > > > 1.1.2      Version 1.1.0  seems to compile and run OK.
> > > > > And as far as the downloadable binaries, version 1.1.2 and 1.1.4
> > > > > segfault when launched.
> > > > Is it a 32-bit or 64-bit system?
> > > 32-bit
> > Are you sure you are launching it correctly? - you launch it with some
> > shell script called launch denemo or some such...

I'm doing:

$ ./Launch_Denemo.sh

It starts to run, and errors out.  Strangely, I just saw that it seems 
to have a /home/<username> (user "jjbenham") hard-coded in it.  Maybe 
THAT's the culprit?  The following is a snippet of the terminal output, 
ending with the fatal seg fault. Please note the apparently hard-coded 
username (there is no "jjbenham" on my system!)


.....
LSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/conf.c:3314:(snd_config_hooks_call) 
Cannot open shared library libasound_module_conf_pulse.so
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/control/control.c:951:(snd_ctl_open_noupdate) 
Invalid CTL hw:0
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/pcm/pcm.c:2217:(snd_pcm_open_noupdate) 
Unknown PCM cards.pcm.rear
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/pcm/pcm.c:2217:(snd_pcm_open_noupdate) 
Unknown PCM cards.pcm.center_lfe
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/pcm/pcm.c:2217:(snd_pcm_open_noupdate) 
Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/pcm/pcm_dsnoop.c:612:(snd_pcm_dsnoop_open) 
unable to open slave
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/pcm/pcm_dmix.c:1018:(snd_pcm_dmix_open) 
unable to open slave
ALSA lib 
/home/jjbenham/public_html/gub/target/linux-x86/src/alsa-1.0.25/src/pcm/pcm_dmix.c:1018:(snd_pcm_dmix_open) 
unable to open slave
Denemo - MESSAGE : The default fluidsynth soundfont has been loaded
Denemo - MESSAGE : Initializing Rubberband
Denemo - MESSAGE : Initializing PortAudio backend
./Launch_Denemo.sh: line 35:  3929 Segmentation fault $PREFIX/bin/denemo


the last line above is the end of the output.


> > > > > But I do wonder, in my API developer ignorance:  could the binaries be
> > > > > made compatible here if, for instance, some functions where statically
> > > > > linked/compiled, as opposed to dynamically?
> > > > essentially it is as if they were linked statically. That is to say,
> > > > they include their own versions of glib and so on, rather than trying to
> > > > use unknown system ones.
> > > I don't understand - are you saying these binaries are already
> > > statically compiled?   Or are you saying yes to the idea that they can
> > > be made more so? That one could compile executables of the latest
> > > versions that would run on old systems, because the newer functions
> > > would be internally contained?
> > I think it is a dynamically linked library,
> whoops! a dynamically linked executable I meant to say
> >   complete with the libraries
> > to link to at run time and a shell script to launch it with the
> > environment set to pick up the correct set of libraries, not the system
> > ones.
> >
> > Richard
> >
> >
> >
> >
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/denemo-devel