The real question is "How to play a sound file on Linux in the same way I can do it on windows?".

this is my experience:

On Windows I do:

uses mmsystem
...
sndPlaySound('filename.wav',0);
...

and it works gracefully.

On Linux I found only the sndfile unit (packages\extra\sndfile\).

This require the presence of sndlife library on the distribution.

In my PC I have Ubuntu 6.06 with libsndfile installed (dynamic library only):

/usr/lib/libsndfile.so.1.0.12
/usr/lib/libsndfile.so.1

So, I try to compile the example sfplay.pp, and after some corrections it compiles but after that the linker stops with the infamous message:

/usr/bin/ld: cannot find -lsndfile
sound.pas(34,1) Error: Error while linking

(note: the -Fl statements in fpc.cfg are tuned on /usr/ and /usr/lib/ so the real problem is that I don't have the static library)

There is a chance to have my program linked on a system where I only have the Dynamic Libray?

thanks
tiziano

Your Linux system is not properly configured for libsndfile development.

You miss the symlink from libsndfile.so -> libsndfile.so.1.0.12

A -lxxx searches for libxxx.so only, not for variants. Create symlinks if necessary or try to install packages that might create symlinks (like -dev packages on RedHat)

neither for other kind of develpment libraries (ncurses, sqlite, etc, etc) indeed.
Each time I try something that needs a link to a library I have to spend my weekends trying to fild what is missing... :-(

Ok, I'll try that, thanks. But the same problem could happen in other PCs where my program could be deployed...

So I turn back to the inital question: there is a more affordable way to play a sound file on a Linux Machine?

thanks
tiziano

> A -lxxx searches for libxxx.so only, not for variants. Create symlinks if > necessary or try to install packages that might create symlinks (like > -dev packages on RedHat)

Ubuntu also has x-dev packages. apt-get install lbsndfile1-dev should fix your problem without need to tinker.

SDL. This library, not counting the graphics part, is ingenious IMHO.

bartek

How this is handled is distro specific. I suggest you read the docs for your distribution to see how it is done.

Ok, I'll try that, thanks. But the same problem could happen in other PCs where my program could be deployed...

Yes and no.

No: It will probably add a dependancy to libsndfile.so.1 (not .so or .so.1.0.12). And that is installed.

Yes: the library must be present, and under that name, and there is no guarantee. But that at least will be ok for Ubuntu.

The only way around it is to enter the complex package building and add a dependancy on the file, a system that varies from distro to distro, unix variant to unix variant (iow, to package your app as a package for each (family of) distribution(s)).

So I turn back to the inital question: there is a more affordable way to play a sound file on a Linux Machine?

No. This is a general library and packaging problematic. No library is 100% guaranteed on Linux, even glibc can be replaced by some embedded variant.

I'm not using Linux, but doesn't ldconfig exist there?

On FreeBSD you can do:

$ ldconfig -r|grep sndfile
        463:-lsndfile.1 => /usr/local/lib/libsndfile.so.1

So you know what's there. AFAIR in the link.sh script in the build directory after fpc failed there are hints on where fpc is searching.

After asking ldconfig after what it found you could look further:

$ ls -l /usr/local/lib/libsndfile*
-rw-r--r-- 1 root wheel 425514 26 Mai 2005 /usr/local/lib/libsndfile.a lrwxr-xr-x 1 root wheel 15 26 Mai 2005 /usr/local/lib/libsndfile.so -> libsndfile.so.1 -rwxr-xr-x 1 root wheel 359904 26 Mai 2005 /usr/local/lib/libsndfile.so.1

(sorry for long lines)

If you set the link a short ldconfig -R rescans the library dirs and it should work.

Try "man ldconfig" and read more about the linux specific switches ...

Hope it helps,
Marc

ok, then I'll drive on the simpler way:

...
with myprocess do
  begin
    commandline:= 'aplay x1.wav';
    execute;
  end;
...

(with a section in a file .ini in order to change the command on distributions where aplay has another name)

Anyway:
simply creating the symlink libsndfile.so did not solve the matter:

sfplay.o: In function `PLAYFILE':sfplay.pp:57: undefined reference to `sf_open_read'
sound.pas(45,1) Error: Error while linking

------
for bartek:
the main reason of my problem is that my PC is not connected to Internet

SDL is great but the problem is the same, not all Linux distributions have it installed.

for mark:
I am not a Linux user, sorry. All that seems too complex to me, but I'll try to investigate :-)

thanks to all
tiziano

Tiziano_mk wrote

for mark: I am not a Linux user, sorry. All that seems too complex to me, but I'll try to investigate :-)

What I wrote is pretty easy, I wish Windows has something like this in the base system - ever had a missing .DLL and windows won't tell you it's name?

The last mail showed you how to ask "is libsndfile there?" and maybe "what version does it have?" depending on th naming conventions of your distribution.

Today I can tell you how to answer the question "does the installed lib really not have function 'sf_open_read'?":

$nm -D /usr/local/libsndfile.so | grep sf_open_read $

Hm, no output, funny.

$ nm -D /usr/local/libsndfile.so | grep sf_open
0000c570 T psf_open_rsrc
00003e44 T sf_open
00003fb0 T sf_open_fd

Ah, see: this version of the lib only has a bunch of other opening functions, not based on a filename but on a file descriptor or similar.

Only guessing here, but:
To support older lib version you can use that function instead of the apparently newer one taking a name or tell people to use at least the version you have installed. Your package manager (rpm, apt, ...) should be able to tell you the version number.

After having had a look into the header
file /usr/local/include/sndfile.h it is pretty clear ...

HTH anyways,
Marc