softwerk-dev

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>My problems started with your custom libraries (gtkmmext, guileconfig,
>midi++, pbd). It appears that when doing a make install each package
>(pbd in particular) installs a m4 macro file into
>/usr/local/share/aclocal/.

Shouldn't happen that way. The tarball is setup to do a 100% local
install into <softwerk-dir>/libs/... Nothing gets installed outside of
that unless you install softwerk itself, which isn't the plan right now.

Did you follow the precise instructions for the tarball compile that
are in README ?

>The configure script for the other libs still reported that my libpbd
>install wasn't sane. Though I noticed it listed the version (1.1.1)
>which satisfied the check (1.1.0). This problem is not occuring now,
>though I was messing with these macros. Not sure why it works now.

This seems to be related to LD_LIBRARY_PATH. I am not sure of the
connection at this point.

>So I WAS getting a seg fault on startup. It appears that was due to an
>invalid path in the softwerkrc.scm to softwerk_ui.rc.

Quite possible. Error checking for user error is very thin at this time.

>How do you configure Softwerk to use an ALSA sequencer client:port? I

You can't. If you want to write the code, feel free. I have little or
no use for the sequencer, and I've never written any code to deal with it.

>Happy to report that it now works (starts up), while I'm writing this
>email. Can't try it though until I can get the sequencer interface
>working.

I take it you have no "true" MIDI devices then ? Just those silly
wavetable synths that require their device driver to translate MIDI
into register fiddling ?

--p

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

Just re-reading this again:

>>My problems started with your custom libraries (gtkmmext, guileconfig,
>>midi++, pbd). It appears that when doing a make install each package
                                             ^^^^^^^^^^^^
                                               |
                  if you typed this  ..........+
	  
then you didn't read the instructions. they say:

  1A: COMPILING FROM A SOURCE TARBALL
  -----------------------------------

  Unpack the source. Then do this:

       cd /where/i/put/the/softwerk/source
       cd libs
       make
       cd ..
       ./configure
       make

Or do you mean when the makefile in ./libs ran "make install" that
this happened ?

--p

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Right. Guess I should follow the README. I originally was using the libraries
>from Quasimodo as thats where the links point to off of the requirements web
>page. If I had followed the README I'm sure I wouldn't have had such a hard
>time :)

Sorry for the confusion. The old "separate libraries installed by
themselves" seemed to be a huge hassle for a lot of people. I still
don't have all the kinks worked out, but hopefully the new system is a
little easier.

>> You can't. If you want to write the code, feel free. I have little or
>> no use for the sequencer, and I've never written any code to deal with it.
>>
>
>Hmm.. Okay.

And sorry if I sound somewhat arrogant about this.

--p

[softwerk-dev] nit picks

[Reynald H. <be...@op...>]

First of all, I can't seem to get to the archives of this list.  All i
get is a Geocrawler page that says error - list not found.

The page I'm looking at is 
http://www.geocrawler.com/redir-sf.php3?list=/softwerk-dev/

Just a few little minor things about the readme file.  I have the other
libraries installed globally on my system since I am interested in pbd's
other programs too.  The README file says I should change libs to
libs-foo, then do a sh autogen.sh

But 
1)there is no libs dir in the CVS version I downloaded
2) autogen.sh looks for the directory libs/share and exits if it doesn't
find it. 
3)ACLOCAL_FLAGS adds the def'n in libs/share/aclocal, which weren't
there. 

So by commenting out the aclocal line, and creating the libs/share
directory, I was easily able to compile, but maybe the readme file
should be changed for this part. (even if I did cvs wrong, the
instructions are to move libs to libs-foo, which would still cause above
problems). 

Now my real problem:
I am using the sample config file, (modified for my soundcard) and I
get:
SoftWerk: [INFO]: guileconfig : found softwerk rc file in:
         .softwerk.rc
ERROR: In procedure read:
ERROR: Unknown # object: #\newline

Not being a guile expert, I have no idea what this means. Any
suggestions?

Thanks,

Reynald

Re: [softwerk-dev] Troubles with Softwerk

[Josh G. <jg...@us...>]

Paul Barton-Davis wrote:

> >Right. Guess I should follow the README. I originally was using the libraries
> >from Quasimodo as thats where the links point to off of the requirements web
> >page. If I had followed the README I'm sure I wouldn't have had such a hard
> >time :)
>
> Sorry for the confusion. The old "separate libraries installed by
> themselves" seemed to be a huge hassle for a lot of people. I still
> don't have all the kinks worked out, but hopefully the new system is a
> little easier.
>

No problem. I know what its like to handle the burden of keeping a program easy
for the common user.

>
> >> You can't. If you want to write the code, feel free. I have little or
> >> no use for the sequencer, and I've never written any code to deal with it.
> >>
> >
> >Hmm.. Okay.
>
> And sorry if I sound somewhat arrogant about this.

Its hard to guess the context of a phrase in an email :) It did come off a little
that way..

<DREAMING BUT NOT FAR OFF>
I'm having this flash on what it would be like to have an online music
composition system. ALSA pretty much already has this capability it seems
(aseqnet). Basically it would be a server that would receive ALSA sequencer
streams from other users and mix them into listenable "channels" that others can
listen to. These channels could either be listened to by an ALSA user client or
perhaps render it with a software MIDI wavetable program and stream via MP3 or
some other online audio format. When native ALSA patch loading becomes available,
a patch loader could be used like any other ALSA client, allowing users to upload
their own patches.
Imagine multiple people composing music from across the world, one person playing
a track, another modifying an effect on the same channel, another playing another
part on a different channel.. All of them trying to cope with the massive latency
:( Ohh well, someday..
</DREAMING BUT NOT FAR OFF>

I noticed you're the author of at least three programs (ardour, softwerk, and
quasimodo). I'm the author of one program of significance (Smurf Sound Font
Editor) and I find it hard enough to keep up on it as much as I would like. How
much success have you had in getting other programmers to help out? I would like
to work on Smurf with others but I haven't gotten that many offers. I myself
don't usually offer to help develop a program, so I guess it has to start
somewhere. Perhaps I'll look into adding sequencer support to Softwerk, just need
to read up on the ++ part of C++ and check out the MIDI related code. Keep up the
good work!
    Josh Green

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

><DREAMING BUT NOT FAR OFF>

Of course, you could just sign up for RocketNetwork. But they don't
give you the source code :)

>I noticed you're the author of at least three programs (ardour,
>softwerk, and quasimodo). I'm the author of one program of
>significance (Smurf Sound Font Editor) and I find it hard enough to
>keep up on it as much as I would like. Ho w much success have you had
>in getting other programmers to help out? 

Very little. Stephane Conversey was one person who made *major*
contributions to Quasimodo. Bill Gribble added libguileconfig to
Quasimodo which was then reused by the others. A couple of people have
contributed small-N-line patches and ideas. And thats about
it. Luckily, I am able to work on these programs more or less as a
full time job (sometimes way more than fulltime!), and I'm glad to be
one of those programmers whose productivity tends to be way up there
(at least when i get enough sleep to actually think about what i'm
doing). But yes, I know what you mean, and it would be much nicer if
there really was a group of people working on any one of "my"
projects. There are lots of rough edges in them that come from me
being the primary user and developer, and thus not exercising certain
code paths that others would do quite naturally. Other people would
both tend to find them, and then hopefully fix them.

[ another reply coming up separately because i want to Cc: it to alsa-devel]

>Keep up the good work!

I'll do what I can :)

--p

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

[ ALSA folks: Josh Green (Smurf sound font editor) was mildly
  contemplating adding the ALSA sequencer as an output destination
  for my MIDI pattern sequencer SoftWerk. I started thinking about
  why it was going to be hard, and it seemed of some relevance to
  this list. Some people may also have ideas about solutions.

  I've set reply-to to point to alsa-devel, because softwerk-dev 
  is member-only.
]

>don't usually offer to help develop a program, so I guess it has to
>start somewhere. Perhaps I'll look into adding sequencer support to
>Softwerk, just n eed to read up on the ++ part of C++ and check out
>the MIDI related code. 

That would be great. You won't really be adding sequencer support to
SoftWerk however, and its probably a bit more complex than it should
be. You'd really be adding the sequencer as a Port type to
libmidi++. And here's why its hard.

Everything that uses libmidi++ would be using the methods defined in
<midi++/channel.h> to deliver MIDI messages of defined types. And they
do. The problem is that by the time these messages get handed to the
underlying MIDI::Port object, they have been rendered as simple byte
streams. The ALSA sequencer (or any other similar system) would exist
as a MIDI::Port type, and so you're going to be handed type-free byte
streams, not typed MIDI messages. I think that the sequencer can be
used to handle this, but certainly not in the intended way unless you
re-parse the data streams so that you deliver typed messages. This
would be an abomination, I think.

This is one of the main reasons for my dislike of the overall design
of the sequencer: it doesn't encapsulate MIDI but requires recoding
the messages as sequencer-API-specific events. This makes life hard
for programs that want to use a common design that allows the
sequencer and raw MIDI devices to be used as equivalent destinations
for data. At least, it seems to.

Instead, it requires the sequencer destination to exist as a more
complex/capable object than a MIDI::Port or alternatively that
MIDI::Port must accept typed messages. The first one messes up a clean
object heirarchy (in essence, the sequencer destination exists in
between the abstraction of a MIDI channel and a MIDI port), and the
second forces a model of what a Port is that doesn't match the reality
of actual devices.

So, as I said, this could be trickier than you (or I) would like :) If
you can see a good re-design of libmidi++ that would solve this
cleanly, I'd be happy to consider doing that. ALSA sequencer support
*is* important.

--p

Re: [alsa-devel] Re: [softwerk-dev] Troubles with Softwerk

[Jaroslav K. <pe...@su...>]

On Sun, 26 Nov 2000, Paul Barton-Davis wrote:

> This is one of the main reasons for my dislike of the overall design
> of the sequencer: it doesn't encapsulate MIDI but requires recoding
> the messages as sequencer-API-specific events. This makes life hard
> for programs that want to use a common design that allows the
> sequencer and raw MIDI devices to be used as equivalent destinations
> for data. At least, it seems to.

I'm not sure, if you know about the virtual midi devices which can be used
like the ordinary rawmidi devices, but the midi stream is parsed to the
sequencer events and versa vice. The virtual midi device behaves like a
sequencer port, so you may connect it to other ports (like the wavetable
sythesizers or midi uart drivers). So far, no changes are needed on your
side. You must only use the ALSA rawmidi devices instead of OSS ones.

Anyway, we can copy our MIDI parser code from the kernel to the user space
and create nice MIDI stream <-> ALSA sequencer converter. It's nothing
complicated for us and it seems that it helps a lot to you. It'll allow
use more features of the ALSA sequencer.

						Jaroslav

-----
Jaroslav Kysela <pe...@su...>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Alas, I have yet to get beyond this point. The sanity check for libpbd
>fails every time, no matter what I've tried. And yes, I've used *only*
>the directions given in the README, so I'm left wondering what in the
>world is wrong with my system. There are no legacy libs lying around
>from previous attempts at QM or Ardour, but for my life I can't figure
>out where things are going wrong. I'm using the tarball: perhaps I
>should try the CVS ? Josh, any suggestions ??

At the end of the config.log file generated by configure is a short
C++ program and the compile command (which spans several lines) (and a
report that it failed) Copy the program to another file, then use the
compile command on it, try to run it (if compilation works) and let me
know the result. There is obviously some possibility for a systematic
snafu here.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> At the end of the config.log file generated by configure is a short
> C++ program and the compile command (which spans several lines) (and a
> report that it failed) Copy the program to another file, then use the
> compile command on it, try to run it (if compilation works) and let me
> know the result. There is obviously some possibility for a systematic
> snafu here.

Paul, I've attached the entire config.log (it's not very long). I'm
missing what you're directing me towards, sorry I'm especially dense
today...

Best regards,

== Dave Phillips

	http://www.bright.net/~dlphilp/index.html
	http://www.bright.net/~dlphilp/linuxsound/

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

Dave - yes, there are no clues there. can you send me the actual
output from configure as it runs ? 

just as one possible hint, after you send me that output, try "rm
config.cache" before another run of configure and see if that helps.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:
 
> Dave - yes, there are no clues there. can you send me the actual
> output from configure as it runs ?
> 
> just as one possible hint, after you send me that output, try "rm
> config.cache" before another run of configure and see if that helps.


Hi, Paul: Here's the configure output, with libpbd already compiled and
existing in libs/lib:

[dlphilp@localhost libs]$ make
echo srcs gtkmmext guileconfig midi++ pbd
srcs gtkmmext guileconfig midi++ pbd
mkdir -p build/gtkmmext build/guileconfig build/midi++ build/pbd
if [ ! -f .configured_pbd ] ; then \
        (cd build/pbd; ../../src/pbd/configure --disable-static
--prefix=/home/dlphilp/softwerk-1.99.1/libs); \
fi
touch .configured_pbd
if [ ! -f .configured_gtkmmext ] ; then \
        (cd build/gtkmmext; ../../src/gtkmmext/configure
--disable-static --prefix=/home/dlphilp/softwerk-1.99.1/libs);\
        fi
loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking cached system tuple... ok
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for c++... (cached) c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for ranlib... (cached) ranlib
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
checking for object suffix... o
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... yes
checking if gcc static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for sigc-config... /usr/local/bin/sigc-config
checking for libsigc++ - version >= 0.8.0... 1.0.1
checking if libsigc++ sane... yes
checking for glib-config... /usr/local/bin/glib-config
checking for GLIB - version >= 1.0.0... yes
checking for gtk-config... /usr/local/bin/gtk-config
checking for GTK - version >= 1.0.0... yes
checking for gtkmm-config... /usr/local/bin/gtkmm-config
checking for GTK-- - version >= 1.2.0... yes
checking for pbd-config...
/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
checking for libpbd - version >= 1.1.0... 1.1.1
checking if libpbd sane... no
configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
appear to be installed
make: *** [.configured_gtkmmext] Error 1


I had already tried removing the cache, but got no joy. Tried it again,
still no joy.

Just for clarity's sake: My system is a beefed-up RH 6.2, with
low-latency patch on kernel 2.4.0-test9 and XFree86 4.01, if that should
matter at all. I upgraded a number of things for the 2.4 instalation,
could there be a mismatch of utils somewhere ??

Best regards,

== Dave Phillips

	http://www.bright.net/~dlphilp/index.html
	http://www.bright.net/~dlphilp/linuxsound/

Currently listening to: "Mutations" by Jean-Claude Risset...ya gotta
love those Shepard tones...!

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>checking for pbd-config...
>/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
>checking for libpbd - version >= 1.1.0... 1.1.1
>checking if libpbd sane... no
>configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
>appear to be installed
>make: *** [.configured_gtkmmext] Error 1

i know you said you did this, and i apologize for having a hard time
believing that the config.log you sent me corresponded to this
sequence of events. the "sanity" test consists of a test program
compilation, and when it fails, the autoconf system prints the program
source out in config.log. Can you take another look (and send it to me ?)

it will be in libs/build/gtkmmext/config.log, which you might not know.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> i know you said you did this, and i apologize for having a hard time
> believing that the config.log you sent me corresponded to this
> sequence of events. the "sanity" test consists of a test program
> compilation, and when it fails, the autoconf system prints the program
> source out in config.log. Can you take another look (and send it to me ?)
> 
> it will be in libs/build/gtkmmext/config.log, which you might not know.

Ah, now we're getting somewhere. I was finding it in libs/src/gtkmmext,
I'm an idiot, sorry... :(  

Here's what that config.log reports:

configure:3020: checking for pbd-config
configure:3056: checking for libpbd - version >= 1.1.0
configure:3110: checking if libpbd sane
configure:3149: c++ -o conftest -g -O2
-I/home/dlphilp/softwerk-1.99.1/libs/include
-I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C 
/home/dlphilp/
softwerk-1.99.1/libs/lib/libltdl.la
-L/home/dlphilp/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lsigc
-lpthread 1>&5
c++: /home/dlphilp/softwerk-1.99.1/libs/lib/libltdl.la: No such file or
directory
configure: failed program was:
#line 3121 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
#endif

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=1 ||
       pbd_minor_version!=1 ||
       pbd_micro_version!=1)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }


So what is libltdl.la and where should I find it ?

Best regards,

== Dave Phillips

	author, The Book Of Linux Music & Sound
(http://www.nostarch.com/lms.htm)
	maintainer, The Linux Soundapps Site
(http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Lush Life" by Johnny Hartman and John
Coltrane...just too beautiful for words...

Re: [softwerk-dev] Troubles with Softwerk

[Josh G. <jg...@us...>]

Paul Barton-Davis wrote:

> >checking for pbd-config...
> >/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
> >checking for libpbd - version >= 1.1.0... 1.1.1
> >checking if libpbd sane... no
> >configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
> >appear to be installed
> >make: *** [.configured_gtkmmext] Error 1
>
> i know you said you did this, and i apologize for having a hard time
> believing that the config.log you sent me corresponded to this
> sequence of events. the "sanity" test consists of a test program
> compilation, and when it fails, the autoconf system prints the program
> source out in config.log. Can you take another look (and send it to me ?)
>
> it will be in libs/build/gtkmmext/config.log, which you might not know.
>

I actually had the same experience.. When I took the output from the libpbd
test program (in config.log) and stuck it in a file and compiled it with the
same compile line configure did, it compiled fine.. I think its the return
value from this test program.. I posted it below. It appears that the
version comparison does a !=.. Since its checking for 1.1.0 wouldn't this be
wrong?
    Josh

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=$pbd_major_version ||
       pbd_minor_version!=$pbd_minor_version ||
       pbd_micro_version!=$pbd_micro_version)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Ah, now we're getting somewhere. I was finding it in libs/src/gtkmmext,
>I'm an idiot, sorry... :(  

No you're not. Many people (not even me until several months back)
didn't know that you could use configure to do what used to be called
VPATH-builds (where the objects are created in a different directory
than the source). Just so you know, I do it this way to avoid
contaminating the source directory, which may be shared by multiple
programs (in the case of a symlink to a CVS-based directory).

ok, on with the show:

>So what is libltdl.la and where should I find it ?

therein lies a painful question :) 

libltdl is a library that is part of libtool, a tool for building a
using shared libraries. it contains a cross-platform API for handling
dynamically linked modules. sort of like g_module from glib, but it
works on many other platforms and believe it or not, even works on
systems that don't have dynamically linked modules at all!

well, you obviously have libtool installed. but my guess is that you
have libtool installed from an RPM that is dated before my convincing
RedHat that libtool is *not* architecture neutral. RedHat never to
used to bother supplying and installing the library that comes with
libtool, and so although you'd get the tools to build the software, if
a program decided to link against the library instead of building it
into itself, boom. I was amazed that this had not come up before. Oh
well, the bleeding edge.

first of all, do this:

      % locate libltdl

just so we can be sure that neither libltdl.so nor libltdl.la exist on
your system. assuming that this is the case:

run, do not walk, to your local RPM server, and pick up a new version
of libtool. after, before or during installing it, verify that it
installed libltdl.la and libltdl.so, almost certainly in /usr/lib.

alternatively, if you're version of it is current, then scream at me.

BTW, this would also have given rise to similar problems with ardour,
quasimodo etc. etc. actually, with any program that wanted to link
against libltdl.

You would not believe the pain that libtool has caused in my life,
mostly around this issue of there being an installed library to go
with it.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> first of all, do this:
> 
>       % locate libltdl
> 
> just so we can be sure that neither libltdl.so nor libltdl.la exist on
> your system. assuming that this is the case:
> 
> run, do not walk, to your local RPM server, and pick up a new version
> of libtool. after, before or during installing it, verify that it
> installed libltdl.la and libltdl.so, almost certainly in /usr/lib.

Wow. Well, before I got your reply I figured out that it was a libtool
problem, and I just happened to have the needed RPMs handy. Now
libltdl.a, libltdl.la, and libltdl.so.0.1.2 are all sitting in /usr/lib,
and /sbin/ldconfig has been run. Still no joy, even after 'make clean'.
Do I perhaps have an older or wrong version of libtool ? (The libs are
dated Sept 2000).
 
> You would not believe the pain that libtool has caused in my life,
> mostly around this issue of there being an installed library to go
> with it.

I'm sort of sensing some of that pain myself... ;)

Best regards,

== Dave Phillips

	author, The Book Of Linux Music & Sound
(http://www.nostarch.com/lms.htm)
	maintainer, The Linux Soundapps Site
(http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: Instrumental music by Folquet de Marseila...love
those troubadours...

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Greetings:

  Paul, I can compile the test prog now, even though the configuration
still fails. Getting closer...

Best regards,

== Dave Phillips

	The Book Of Linux Music & Sound (http://www.nostarch.com/lms.htm)
	The Linux Soundapps Site (http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Low Speed" by Otto Luening

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Wow. Well, before I got your reply I figured out that it was a libtool
>problem, and I just happened to have the needed RPMs handy. Now
>libltdl.a, libltdl.la, and libltdl.so.0.1.2 are all sitting in /usr/lib,
>and /sbin/ldconfig has been run. Still no joy, even after 'make clean'.
>Do I perhaps have an older or wrong version of libtool ? (The libs are
>dated Sept 2000).

ok, so try "rm config.cache" again, then send me the results (both the
screen output and config.log.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> ok, so try "rm config.cache" again, then send me the results (both the
> screen output and config.log.

Okay, see below.

Btw, I downloaded, built, and installed the latest libtool package from
the GNU site (libtool-1.3.5). I cleared the old versions (or I think I
have), and ran ldconfig again. Softwerk configuration still dies at the
same point:

From the screen:

make[1]: Leaving directory
`/home/dlphilp/softwerk-1.99.1/libs/build/pbd'
if [ ! -f .configured_gtkmmext ] ; then \
        (cd build/gtkmmext; ../../src/gtkmmext/configure
--disable-static --prefix=/home/dlphilp/softwerk-1.99.1/libs);\
        fi
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking cached system tuple... ok
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for c++... c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for ranlib... ranlib
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
updating cache ./config.cache
checking for object suffix... o
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... yes
checking if gcc static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for sigc-config... /usr/local/bin/sigc-config
checking for libsigc++ - version >= 0.8.0... 1.0.1
checking if libsigc++ sane... yes
checking for glib-config... /usr/local/bin/glib-config
checking for GLIB - version >= 1.0.0... yes
checking for gtk-config... /usr/local/bin/gtk-config
checking for GTK - version >= 1.0.0... yes
checking for gtkmm-config... /usr/local/bin/gtkmm-config
checking for GTK-- - version >= 1.2.0... yes
checking for pbd-config...
/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
checking for libpbd - version >= 1.1.0... 1.1.1
checking if libpbd sane... no
configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
appear to be installed
make: *** [.configured_gtkmmext] Error 1


From config.log:

configure:604: checking host system type
configure:652: checking host system type
configure:673: checking target system type
configure:691: checking build system type
configure:716: checking cached system tuple
configure:762: checking for a BSD compatible install
configure:815: checking whether build environment is sane
configure:872: checking whether make sets ${MAKE}
configure:918: checking for working aclocal
configure:931: checking for working autoconf
configure:944: checking for working automake
configure:957: checking for working autoheader
configure:970: checking for working makeinfo
configure:994: checking for c++
configure:1026: checking whether the C++ compiler (c++  ) works
configure:1042: c++ -o conftest    conftest.C  1>&5
configure:1068: checking whether the C++ compiler (c++  ) is a
cross-compiler
configure:1073: checking whether we are using GNU C++
configure:1082: c++ -E conftest.C
configure:1101: checking whether c++ accepts -g
configure:1139: checking for gcc
configure:1252: checking whether the C compiler (gcc  ) works
configure:1268: gcc -o conftest    conftest.c  1>&5
configure:1294: checking whether the C compiler (gcc  ) is a
cross-compiler
configure:1299: checking whether we are using GNU C
configure:1308: gcc -E conftest.c
configure:1327: checking whether gcc accepts -g
configure:1370: checking for ld used by GCC
configure:1433: checking if the linker (/usr/bin/ld) is GNU ld
GNU ld version 2.9.1 (with BFD 2.9.1.0.24)
configure:1520: checking for ranlib
configure:1548: checking for BSD-compatible nm
configure:1585: checking whether ln -s works
ltconfig:590: checking for object suffix
ltconfig:591: gcc -c -g -O2  conftest.c 1>&5
ltconfig:721: checking if gcc PIC flag -fPIC works
ltconfig:722: gcc -c -g -O2 -fPIC -DPIC  conftest.c 1>&5
ltconfig:764: checking if gcc supports -c -o file.o
ltconfig:765: gcc -c -g -O2 -c -o conftest2.o  conftest.c 1>&5
ltconfig:792: checking if gcc supports -c -o file.lo
ltconfig:793: gcc -c -g -O2 -c -o conftest.lo  conftest.c 1>&5
ltconfig:844: checking if gcc supports -fno-rtti -fno-exceptions
ltconfig:845: gcc -c -g -O2 -fno-rtti -fno-exceptions -c conftest.c 
conftest.c 1>&5
ltconfig:888: checking if gcc static flag -static works
ltconfig:889: gcc -o conftest -g -O2   -static conftest.c  1>&5
GNU ld version 2.9.1 (with BFD 2.9.1.0.24)
ltconfig:1478: checking if global_symbol_pipe works
ltconfig:1479: gcc -c -g -O2  conftest.c 1>&5
ltconfig:1482: eval "/usr/bin/nm -B conftest.o | sed -n -e 's/^.*[     
]\([ABCDGISTW]\)[       ][      ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1
\2\3 \3/p' > conftest.nm"
ltconfig:1534: gcc -o conftest -g -O2 -fno-builtin -fno-rtti
-fno-exceptions   conftest.c conftstm.o 1>&5
configure:1963: checking for sigc-config
configure:1999: checking for libsigc++ - version >= 0.8.0
configure:2054: checking if libsigc++ sane
configure:2100: c++ -o conftest -g -O2 -I/usr/local/lib/sigc++/include
-I/usr/local/include   conftest.C  -L/usr/local/lib -lsigc -lpthread
1>&5
configure:2202: checking for glib-config
configure:2237: checking for GLIB - version >= 1.0.0
configure:2336: gcc -o conftest -g -O2 -I/usr/local/lib/glib/include
-I/usr/local/include   conftest.c -L/usr/local/lib -lglib  1>&5
configure:2472: checking for gtk-config
configure:2507: checking for GTK - version >= 1.0.0
configure:2608: gcc -o conftest -g -O2 -I/usr/local/lib/glib/include
-I/usr/local/include -I/usr/X11R6/include   conftest.c -L/usr/local/lib
-L/usr/X11R6/lib -lgtk -
lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm  1>&5
configure:2735: checking for gtkmm-config
configure:2771: checking for GTK-- - version >= 1.2.0
configure:2885: c++ -o conftest -g -O2 -I/usr/local/lib/gtkmm/include
-I/usr/local/include -I/usr/local/lib/glib/include -I/usr/X11R6/include
-I/usr/local/lib/sigc++
/include   conftest.C  -rdynamic -L/usr/local/lib -L/usr/X11R6/lib
-lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lm
-lsigc -lpthread 1>&5
In file included from /usr/include/g++-2/stl_alloc.h:57,
                 from /usr/include/g++-2/alloc.h:21,
                 from /usr/include/g++-2/std/bastring.h:39,
                 from /usr/include/g++-2/string:6,
                 from /usr/local/include/gtk--/base.h:28,
                 from /usr/local/include/gtk--.h:70,
                 from configure:2808:
/usr/include/stdlib.h:520: warning: declaration of `exit(int)' throws
different exceptions
configure:2805: warning: previous declaration here
configure:3020: checking for pbd-config
configure:3056: checking for libpbd - version >= 1.1.0
configure:3110: checking if libpbd sane
configure:3149: c++ -o conftest -g -O2
-I/home/dlphilp/softwerk-1.99.1/libs/include
-I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C 
-L/home/dlphil
p/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lltdl -lsigc
-lpthread 1>&5
configure: failed program was:
#line 3121 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
#endif

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=1 ||
       pbd_minor_version!=1 ||
       pbd_micro_version!=1)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }



Also this from /usr/local/lib:

[dlphilp@localhost lib]$ ls -l libltd*
-rw-r--r--   1 root     root        42742 Nov 27 15:17 libltdl.a
-rwxr-xr-x   1 root     root          647 Nov 27 15:17 libltdl.la
lrwxrwxrwx   1 root     root           16 Nov 27 15:17 libltdl.so ->
libltdl.so.0.1.2
lrwxrwxrwx   1 root     root           16 Nov 27 15:17 libltdl.so.0 ->
libltdl.so.0.1.2
-rwxr-xr-x   1 root     root        44631 Nov 27 15:17 libltdl.so.0.1.2



And from /usr/local/bin:

[dlphilp@localhost bin]$ ls -l libt*
-rwxr-xr-x   1 root     root       118871 Nov 27 15:17 libtool
-rwxr-xr-x   1 root     root         8117 Nov 27 15:17 libtoolize


Everything's been linked to /usr/lib and /usr/bin as well. The default
installation was to /usr/local, RH had the stuff in /usr. I also
uninstalled the original RH RPM.

Best regards,

== Dave Phillips

	The Book Of Linux Music & Sound (http://www.nostarch.com/lms.htm)
	The Linux Soundapps Site (http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Notjustmoreidlechatter" by Paul Lansky

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

So, when you put this into conftest.C:

----------------------------------------------------------------------
#line 3121 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int); // BTW - I want to know where this comes from!
#endif

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=1 ||
       pbd_minor_version!=1 ||
       pbd_micro_version!=1)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }
----------------------------------------------------------------------

and then try to compile it with :

----------------------------------------------------------------------
c++ -o conftest -g -O2 \
-I/home/dlphilp/softwerk-1.99.1/libs/include \
-I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C  \
-L/home/dlphil \
p/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lltdl -lsigc \
-lpthread 
----------------------------------------------------------------------

what happens ?

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Greetings:

  It compiled fine, not one complaint. So what do you think is happening
?

  The extern came straight from the config.log file, no changes made
here.

Best regards,

== Dave Phillips


Paul Barton-Davis wrote:
> 
> So, when you put this into conftest.C:
> 
> ----------------------------------------------------------------------
> #line 3121 "configure"
> #include "confdefs.h"
> #ifdef __cplusplus
> extern "C" void exit(int); // BTW - I want to know where this comes from!
> #endif
> 
> #include <stdio.h>
> #include <pbd/version.h>
> #include <pbd/transmitter.h>
> 
> Transmitter error(Transmitter::Error);
> Transmitter info(Transmitter::Info);
> Transmitter warning(Transmitter::Warning);
> Transmitter fatal(Transmitter::Fatal);
> 
> int main(int argc,char **argv)
>   {
>    if (pbd_major_version!=1 ||
>        pbd_minor_version!=1 ||
>        pbd_micro_version!=1)
>      { printf("(%d.%d.%d) ",
>          pbd_major_version,pbd_minor_version,pbd_micro_version);
>        return 1;
>      }
>   }
> ----------------------------------------------------------------------
> 
> and then try to compile it with :
> 
> ----------------------------------------------------------------------
> c++ -o conftest -g -O2 \
> -I/home/dlphilp/softwerk-1.99.1/libs/include \
> -I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C  \
> -L/home/dlphil \
> p/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lltdl -lsigc \
> -lpthread
> ----------------------------------------------------------------------
> 
> what happens ?
> 
> _______________________________________________
> Softwerk-dev mailing list
> Sof...@li...
> http://lists.sourceforge.net/mailman/listinfo/softwerk-dev

--

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>  It compiled fine, not one complaint. So what do you think is happening

ok, so now run it and tell me what it prints out ...

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

In message <3A2...@br...>you write:
>Greetings:
>
>  It compiled fine, not one complaint. So what do you think is happening

i have an idea. a fairly good idea. and its a problem in every single
library of mine. observe:

>> int main(int argc,char **argv)
>>   {
>>    if (pbd_major_version!=1 ||
>>        pbd_minor_version!=1 ||
>>        pbd_micro_version!=1)
>>      { printf("(%d.%d.%d) ",
>>          pbd_major_version,pbd_minor_version,pbd_micro_version);
>>        return 1;
>>      }
>>   }

now, what do you suppose this program returns if the versions numbers
*do* match ?

10 extra points if you can say "its undefined". 

once i hear from you the result of running it, i'll put together a new
version of the tarball. you can either add:

	return 0;

as the final statement of main(), or get the new tarball, heh,
heh. strictly speaking, all my libraries need this. i'll leave it to
you whether to patch them by hand (for library "foo", its
.../softwerk/libs/src/foo/foo.m4 that contains the relevant source code)

BTW, I got this program from some other GNU auto*-using program. I
wonder how many other programs have this problem ? or was it just me
forgetting to add the "return 0;" in place.

I hope this is really the problem - its a giant discovery for me, even
if its not the problem. so thanks.

--p

ps. for CVS users, the changes have just been committed.

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Greetings:

  Still no joy. At this point my head is approaching the consistency of
setting concrete. I'll try again tomorrow, gotta catch some zzzsss...

  Btw, when I ran conftest outside of the SoftWerk home directory I
received this message:

./conftest: error in loading shared libraries: libpbd-1-1-1.so: cannot
open shared object file: No such file or directory

   And 'ldd conftest' reported:

[dlphilp@localhost dlphilp]$ ldd conftest
        libpbd-1-1-1.so => not found
        libltdl.so.0 => /usr/lib/libltdl.so.0 (0x4001d000)
        libsigc-1.0.so.0 => /usr/local/lib/libsigc-1.0.so.0 (0x40021000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40030000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x40041000)
        libm.so.6 => /lib/libm.so.6 (0x40083000)
        libc.so.6 => /lib/libc.so.6 (0x4009f000)
        libdl.so.2 => /lib/libdl.so.2 (0x40193000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


   Note that I built conftest in /home/dlphilp. I added the complete
paths for the includes in conftest.C. I'm yawning now, been up too
long...

Best regards,

== Dave Phillips

	The Book Of Linux Music & Sound (http://www.nostarch.com/lms.htm)
	The Linux Soundapps Site (http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Heliosphan" by Aphex Twin


Paul Barton-Davis wrote:
> 
> In message <3A2...@br...>you write:
> >Greetings:
> >
> >  It compiled fine, not one complaint. So what do you think is happening
> 
> i have an idea. a fairly good idea. and its a problem in every single
> library of mine. observe:
> 
> >> int main(int argc,char **argv)
> >>   {
> >>    if (pbd_major_version!=1 ||
> >>        pbd_minor_version!=1 ||
> >>        pbd_micro_version!=1)
> >>      { printf("(%d.%d.%d) ",
> >>          pbd_major_version,pbd_minor_version,pbd_micro_version);
> >>        return 1;
> >>      }
> >>   }
> 
> now, what do you suppose this program returns if the versions numbers
> *do* match ?
> 
> 10 extra points if you can say "its undefined".
> 
> once i hear from you the result of running it, i'll put together a new
> version of the tarball. you can either add:
> 
>         return 0;
> 
> as the final statement of main(), or get the new tarball, heh,
> heh. strictly speaking, all my libraries need this. i'll leave it to
> you whether to patch them by hand (for library "foo", its
> .../softwerk/libs/src/foo/foo.m4 that contains the relevant source code)
> 
> BTW, I got this program from some other GNU auto*-using program. I
> wonder how many other programs have this problem ? or was it just me
> forgetting to add the "return 0;" in place.
> 
> I hope this is really the problem - its a giant discovery for me, even
> if its not the problem. so thanks.
> 
> --p
> 
> ps. for CVS users, the changes have just been committed.
> 
> _______________________________________________
> Softwerk-dev mailing list
> Sof...@li...
> http://lists.sourceforge.net/mailman/listinfo/softwerk-dev

--