Date: Thu, 21 Dec 2000 22:45:39 -0500 From: Will Andrews <will@physics.purdue.edu> To: Anarcat <beaupran@IRO.UMontreal.CA> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: Porting ecasound suite to FreeBSD Message-ID: <20001221224539.J328@argon.firepipe.net> In-Reply-To: <87puilbdwu.wl@localhost.anarcat.yi.org>; from beaupran@IRO.UMontreal.CA on Thu, Dec 21, 2000 at 05:36:01PM -0500 References: <87puilbdwu.wl@localhost.anarcat.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 21, 2000 at 05:36:01PM -0500, Anarcat wrote: > [Please CC: I'm not on the list] > [I should have posted here 3 months ago.] :-) > Ecasound is a command-line tool and a library that is the basis for a > few other packages. There is QtEcasound (a Qt GUI) and ecawave (a wave > editor that uses QtEcasound libs). For the rest of the hype about > ecasound, see the webpage. :) That said, it's very nice and I want it > on FreeBSD. :) Sounds neat. > First, there is the eternal pthread nightmare. I had to patch the > configure scripts to make them use '-pthread' and add '-D_THREAD_SAFE' > to compilation. pthread is only a nightmare because of the lack of a standard as to how to link with it properly. And even then a simple perl regex command can fix a configure script. > Second, I can't find mlockall() on FreeBSD. It's declared in > /usr/include/sys/mmap.h (AFAIR). It's supposed to be > POSIX.1b. Grepping through /usr/src, I found it in the kernel and some #include <sys/mman.h> > Ok. Let's come back on these "libc" warnings. I don't get > it. setkey(3) *is* present on my system. It's a plain 4.2-STABLE > install, for Knuth's sake! There is not a single occurence of > mktemp() or f_prealloc() in ecasound's source!! There is, however, an > occurence of gets() in ecasound's readline lib. But I disabled it! The problem lies with the fact your makefile makes it link explicitly with -lc_r. You are _not_ supposed to do this - gcc takes care of linking with the standard libraries (e.g. -lc, -lc_r, and others). > For tmpnam(), it *is* used in the code. However, mkstemp() *cannot* > be used since tmpnam() is used to generate a name for a > *fifo*. mkstemp() creates a file. What do I do with this mess? You use mkfifo() to make the fifo. I found the tmpnam() call in the code.. not sure how it can be integrated into the code. Probably better just to ignore the warning. > Anyways, I was able to compile the program, the libs, and all the > stuff... That is, I installed the libs in /usr/local/lib and did a > ldconfig to refresh that. After that, I tried to compile > qtecasound. And there comes the weird part: > > c++ -lecasound -lkvutils -pthread test.c -o test > > does not link, but > > c++ -L/usr/local/lib -lecasound -lkvutils -pthread test.c -o test > > does. That is, in the first, I get something like: > > /usr/libexec/elf/ld: cannot find -lecasound > > But it's there: > $ ldconfig -r | grep ecasound > 232:-lecasound.7 => /usr/local/lib/libecasound.so.7 > 254:-lecasoundc.0 => /usr/local/lib/libecasoundc.so.0 > $ > > Yukl. Weird. So that's all i can do for now... This is to be expected. It's the standard way you do things. The compiler must be told where the libraries are if they are not in the standard library search paths (usually just /usr/lib). Or else you'll run into a huge mess of namespace conflicts. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001221224539.J328>