Loading ...
Sorry, an error occurred while loading the content.

Re: problem installing mt-daapd .0.2.0

Expand Messages
  • e_matibag
    ... list ... look ... a ... somewhat. ... required ... there ... (since ... transfer ... made ... just ... Yes, I installed the all the required pacakages.
    Message 1 of 7 , Jan 1, 2005
    • 0 Attachment
      --- In LinkStation_General@yahoogroups.com, Steve Lemke <steve@l...>
      wrote:
      > "e_matibag" <rhinoed@a...> wrote:
      >
      > > when installing mt-daapd, it looks like it errors out.
      > > I check to see if it is running by confirming using "ps -A" and
      list
      > > no mt-daapd running
      > >
      > > here is the last lines of install message.
      > >
      > > /opt/mt-daapd-0.2.0/src/db-gdbm.c:1184: relocation truncated to
      fit:
      > > R_PPC_REL24
      > > pthread_rwlock_rdlock
      > > /opt/mt-daapd-0.2.0/src/db-gdbm.c:1221: undefined reference to
      > > `pthread_rwlock_u
      > > nlock'
      > > /opt/mt-daapd-0.2.0/src/db-gdbm.c:1221: relocation truncated to
      fit:
      > > R_PPC_REL24
      > > pthread_rwlock_unlock
      > > collect2: ld returned 1 exit status
      > > make[2]: *** [mt-daapd] Error 1
      > > make[2]: Leaving directory `/mnt/opt/mt-daapd-0.2.0/src'
      > > make[1]: *** [install] Error 2
      > > make[1]: Leaving directory `/mnt/opt/mt-daapd-0.2.0/src'
      > > make: *** [install-recursive] Error 1
      > >
      > > Does anyone know what means?
      >
      > Not sure. I just installed it and it worked fine, though if you
      look
      > in the archives from this month you'll see a message I posted with
      a
      > bunch of feedback on how the instructions might be improved
      somewhat.
      >
      > Are you sure you downloaded and properly unpacked all of the
      required
      > tar files?
      >
      > It looks like you're using mt-daapd version 0.2.0 (the "stable"
      > release). Looking at http://mt-daapd.sourceforge.net it appears
      there
      > is a newer 0.2.1-pre2 dev release (from 11/26). The version I
      > downloaded just happened to be the latest and greatest from CVS
      (since
      > I built this before realizing there were older "stable" releases
      > available). So, the version I'm running is cvs-20041207.
      >
      > Interestingly, it looks like on 12/29, compressed song info
      transfer
      > was added (something I noticed was definitely lacking in previous
      > versions with my 800+ CD collection), and on 12/30 some fixes were
      made
      > for building on the LinkStation (perhaps broken on 12/29 since the
      > 12/07 build worked fine on my Linkstation).
      >
      > Anyone else running the 12/30 build or later?
      >
      > Also, has anyone else "updated" to a newer mt-daapd after already
      > installing and building? Is there anything tricky to know? Do I
      just
      > download it, unpack it, and "make install" like before?
      >
      > Happy New Year to all...
      > --Steve


      Yes, I installed the all the required pacakages. Autoconf
      automake
      binutils
      bison
      glex
      g++
      gcc
      gdb
      glibc
      libgdbm
      libstdc
      m4
      make
      testutils
      I obtained these packages from revogear's website.
      installed from the root. My /usr is syslinked to /mnt/usr as not to
      fill up the root directory.

      it looks like a lpthread configurtion problem. being a newbie at
      linux. How does one that get fixed?
      would sysmlink cause that problem?
    • Steve Lemke
      ... OK, so it wasn t just me. :-) I timed the earlier (December) build at 35 seconds, and timed the 12/30 build at over 40 seconds. I thought it seemed odd
      Message 2 of 7 , Jan 2, 2005
      • 0 Attachment
        Thom Mason wrote:
        > I'm running the Dec. 30 version on my Linkstation. The compressed
        > song info transfer actually increases time for my 3600 song library
        > slightly. This was what broke the Dec 29 version compile on the
        > linkstation. The Dec. 30 tarball is a straightforward make install.

        OK, so it wasn't just me. :-)

        I timed the earlier (December) build at 35 seconds, and timed the 12/30
        build at over 40 seconds. I thought it seemed odd that turning on
        compression would do this.

        Has anyone looked at the code changes? Is it compressed on the fly
        (perhaps slowing down the transfer on the LinkStation) and if so,
        wouldn't it make more sense to pre-compress the list when it's built
        after the database scan, such that the incoming list request would
        result in a simple (and hopefully faster) transfer of a pre-built and
        pre-compressed list?
        --Steve
      Your message has been successfully submitted and would be delivered to recipients shortly.