gmediaserver-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gmediaserver-devel] Problem on FreeBSD


From: White FrosT
Subject: Re: [gmediaserver-devel] Problem on FreeBSD
Date: Sun, 15 Oct 2006 23:56:32 +0200
User-agent: Thunderbird 1.5.0.7 (Windows/20060909)

Hi all,

Still working on it here. Seems I have a working libupnp here and it is recognized, it is 1.4.1 from ports, devel/upnp. See attached config.log. However, seems now I have a libmagic problem. The gmake output ends with:

gcc -Wall -I.. -D_THREAD_SAFE -pthread -I/usr/local/include    -g -O2   -o gmediaserver  connectmgr.o contentdir.o interface.o logging.o upnp.o webserver.o webclient.o main.o metadata.o url.o search-lexer.o search-parser.o intutil.o hmap.o tmap.o strutil.o strbuf.o ../lib/libgnu.a ../uuid/libuuid.a -L/usr/local/lib -lupnp -lthreadutil -lixml     -lmagic /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib
/usr/lib/libmagic.so: undefined reference to `inflate'
/usr/lib/libmagic.so: undefined reference to `inflateEnd'
/usr/lib/libmagic.so: undefined reference to `inflateInit2_'


Looks like libmagic on FreeBSD is missing something?

Best regards,
Olaf

Oskar Liljeblad wrote:
On Monday, September 04, 2006 at 16:55, James E. Flemer wrote:
  
By the way, the FreeBSD libupnp-1.2.1 port that I made does *NOT* 
install the package config file (libupnp.pc).  For that matter it 
doesn't install a static library (libupnp.a) or the libtool junk 
(libupnp.la).  So, Olaf, you might well have some mix of upnp libraries.

Oskar, which of these two upnp libraries do you develop with:
  (1) http://sourceforge.net/projects/upnp/
or
  (2) http://sourceforge.net/projects/pupnp/

I use version 1.2.1 of (1), and that is what the FreeBSD port I made is 
for.  It looks like since I last worked on GMS, that (1) has forked and 
created (2).
    

So far I've been working with the original one, (1). GMediaServer should
support both, and in future releases I will probably test against 'pupnp'
(2) instead.

Regards,

Oskar


  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]