#25 Fix for buildling on FreeBSD

closed-fixed
None
5
2004-04-30
2004-03-05
No

Hi, in order for xvidcap to build on FreeBSD I did the following after running autoconf:
- Replaced "-lpthread" with "-pthread" in AM_LDFLAGS in src/Makefile

- Changed fdatasync to fsync in src/capture.c
autoconf checks for the presence of fdatasync, so it should be easy to fix.

I built xvidcap 1.1.3, which now works as a charm.

Discussion

  • Řyvind Hallsteinsen

    autoconf log

     
  • Karl H. Beckers

    Karl H. Beckers - 2004-03-08

    Logged In: YES
    user_id=782084

    (update)
    thanks for the input.
    I agree item 2 should be trivial.
    What about libpthread? You are saying: To link against
    libpthread on
    FreeBSD you do NOT tell gcc to link with -lpthread but use a
    special
    flag? So, gcc on FreeBSD is different?
    I was just about considering checking for libpthread in
    configure, so
    this would be valuable information.

    Karl.

     
  • Řyvind Hallsteinsen

    Logged In: YES
    user_id=149780

    I'm sorry for the poor description, allow me to give you a better
    explanation.

    In pthread(3) on freebsd you find the following description:

    "The current FreeBSD POSIX thread implementation is built in the
    library libc_r which contains both thread-safe libc functions and the
    thread functions. This library replaces libc for threaded applications.

    By default, libc_r is built as part of a 'make world'. To disable the
    build of libc_r you must supply the '-DNOLIBC_R' option to make(1).

    A FreeBSD specific option has been added to gcc to make linking
    threaded processes simple. gcc -pthread links a threaded process
    against libc_r instead of libc."

    And in gcc(1):
    "FreeBSD SPECIFIC OPTIONS
    -pthread
    Link a user-threaded process against libc_r instead of libc."

    However, through a bit of googling I found that the use of "-pthread" is
    depricated in favour of using ${PTHREAD_LIBS}. PTHREAD_LIBS is
    set by the freebsd 'make' program automatically through inclusion of
    /etc/make.conf (allthough only if PTHREAD_LIBS is set in make.conf,
    of course. On a default installation it is not set). Another thing is that if
    one uses gnu make, then /etc/make.conf is not read at all.

    One can choose to fall back to "-lc_r" or whatever one chooses if
    PTHREAD_LIBS is not set. I see that the freebsd ports-system has
    some scripts available for the ports that does this:

    # --------------------
    # Get __FreeBSD_version
    .if !defined(OSVERSION)
    .if exists(/sbin/sysctl)
    OSVERSION!= /sbin/sysctl -n kern.osreldate
    .else
    OSVERSION!= /usr/sbin/sysctl -n kern.osreldate
    .endif
    .endif
    # --------------------

    and then:
    # --------------------
    ".if ${OSVERSION} < 500016
    PTHREAD_CFLAGS= -D_THREAD_SAFE
    PTHREAD_LIBS= -pthread
    .else
    PTHREAD_CFLAGS= -D_THREAD_SAFE
    PTHREAD_LIBS= -lc_r
    .endif
    # --------------------

    Over to something completely different:
    I think I was a bit hasty when I said that it worked as a charm. I'm
    experiencing terrible performance compared to an acquaintance of mine
    running xvidcap in linux. In 1280x1024x16 I'm only able to capture at
    1fps if I'm not to drop any frames on an Intel P4 2.4GHz. I've
    experimented with different sized capture-windows, encoders etc.
    Allthough it does get better with a smaller capture windows, it isn't
    comparable to my acquaintance says he is able to capture 1154x864 in
    10fps with only a few losts frames on an AMD Duron 1.2GHz.

    Also, the computer becomes very unresponsive when I'm capturing. It's
    like it stops completely every time a frame is captured (I can feel it
    when I type in an xterm, if you know what I mean :-).

    Do you have any ideas what this might come from? Defect threading
    perhaps?

    I also have some problems with segfaults when I move the cursor in and
    out of the capture window during capture. Haven't looked into that,
    should probably be possible for someone knowledgeable with gdb to find
    the problem. I, however, do not know my way around gdb :-)

     
  • Řyvind Hallsteinsen

    Logged In: YES
    user_id=149780

    Reject my information about performance problems in freebsd.
    The problem is actually related to xfree86' Xserver. I've
    tried three different computers with both freebsd and linux
    with just as poor results in both OS'es. If I use vncserver
    it goes smooth as jazz. Hardly uses cpu and the system is
    just as responsive as if xvidcap wasn't capturing. We can
    discuss this in another thread/forum/.. if this is of interest.

     
  • Karl H. Beckers

    Karl H. Beckers - 2004-03-15

    Logged In: YES
    user_id=782084

    (update)
    implemented the fixes and a couple of other portability
    related things

    will try to upload tonight (CET) ... watch for a tag
    r1_1_3p1.

    Please let me know if this works better, because I have
    no way to test on FreeBSD.

    Karl.

     
  • Karl H. Beckers

    Karl H. Beckers - 2004-03-15
    • assigned_to: nobody --> charly4711
    • status: open --> open-fixed
     
  • Řyvind Hallsteinsen

    Logged In: YES
    user_id=149780

    With some small syntax-fixes (see attached diff) the configure-script
    works almost as it should.

    It correctly adds "-lc_r" to the LIBS-variable in ./Makefile and
    src/Makefile
    It does not add "-lc_r" to the AM_LDFLAGS-variable in src/Makefile - it
    still has "-lpthread" there.

    yvind

     
  • Karl H. Beckers

    Karl H. Beckers - 2004-04-03

    Logged In: YES
    user_id=782084

    (update)
    - added the fixes to configure.ac from the diff provided.
    - also fixed src/Makefile.am which still had a hardcoded
    -lphtreads in it
    from before I was checking for libpthreads

    should be working alright, now.
    Will be closing this one upon confirmation that it does.

    Thanks,

    Karl.

     
  • Karl H. Beckers

    Karl H. Beckers - 2004-04-03

    Logged In: YES
    user_id=782084

    (update)
    btw. the CVS tag is r1_1_3p2

     
  • Thierry Thomas

    Thierry Thomas - 2004-04-29

    Logged In: YES
    user_id=367145

    xvidcap is now in the FreeBSD ports tree.

    About pthread: it's better to use PTHREAD_CFLAGS and
    PTHREAD_LIBS to let it work on different FreeBSD versions.

    About fdatasync and a problem with <sys/time.h> in
    FreeBSD-4, I've applied to patches:

    --- src/xt_control.c.orig Sat Feb 14 21:48:14 2004
    +++ src/xt_control.c Sun Apr 25 10:56:23 2004
    @@ -29,6 +29,9 @@
    #include <stdlib.h>
    #include <limits.h> /* PATH_MAX */
    #include <ctype.h> /* isdigit() */
    +#ifdef HAVE_SYS_TIME_H
    +# include <sys/time.h>
    +#endif
    #include <X11/Intrinsic.h>
    #include <X11/StringDefs.h>
    #include <X11/Shell.h>

    --- src/capture.c.orig Sat Feb 14 21:14:20 2004
    +++ src/capture.c Sun Apr 25 01:21:53 2004
    @@ -643,7 +643,11 @@
    (*job->close) (fp);
    else if (job->flags & FLG_SYNC) {
    if (job->open == (void *(*)(char *, char*))fopen)
    +#ifdef HAVE_FDATASYNC
    fdatasync(fileno(fp));
    +#else
    + fsync(fileno(fp));
    +#endif
    }

    /* substract the time we needed for creating and saving

     
  • Řyvind Hallsteinsen

    Logged In: YES
    user_id=149780

    Don't know if it's of interest anymore, but 1.1.3p2 worked fine after I
    attached brackets around the if-statement on line 5557 in configure

    Thus:
    Line 5557: if [ -x /sbin/sysctl ] ; then

     
  • Karl H. Beckers

    Karl H. Beckers - 2004-04-30
    • status: open-fixed --> closed-fixed
     
  • Karl H. Beckers

    Karl H. Beckers - 2004-04-30

    Logged In: YES
    user_id=782084

    (closing)
    Of course ...
    configure.ac has the square brackets but autoconf loses them
    (which is probably normal autoconf behaviour ... anyway).
    Changed
    it to (test -x /sbin/sysctl ) which is to be considered more
    portable
    anyways.
    So, I will consider this bug fixed (r1_1_3p3) and closed.

    karl.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks