Re: Linux compatibility with more than one Linux installed?
The X server has a unix socket somewhere in /tmp. Normally this is used instead of a TCP connection to the localhost. You need to change the DISPLAY env-variable to use a TCP connection, or you need o make the unix socket available to the chrooted linux-env. The linuxulator in FreeBSD is nearly linux 2.6.16 compatible. We lack inotify and epoll support which the 2.6.16 kernel normally supports. If your system does not depend upon inotify, epoll and anything newer than 2.6.16, it should work. If you give it a try, please report success or failure to emulat...@freebsd.org. Bye, Alexander. Now I might have something to try, but it is very unlikely that I would build a Linux kernel = 2.6.16, especially with new hardware that might need the latest drivers. I will primarily want to run Linux natively rather than under FreeBSD. I think emulators/linux_dist-gentoo-stage3 and emulators/linux_base-gentoo-stage3 must use kernel far beyond 2.6.16. But I think, when chrooting into Linux from FreeBSD, FreeBSD kernel is the one in effect. Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux compatibility with more than one Linux installed?
On Tue, Dec 6, 2011 at 3:53 AM, Thomas Mueller mueller6...@bellsouth.net wrote: The X server has a unix socket somewhere in /tmp. Normally this is used instead of a TCP connection to the localhost. You need to change the DISPLAY env-variable to use a TCP connection, or you need o make the unix socket available to the chrooted linux-env. The linuxulator in FreeBSD is nearly linux 2.6.16 compatible. We lack inotify and epoll support which the 2.6.16 kernel normally supports. If your system does not depend upon inotify, epoll and anything newer than 2.6.16, it should work. If you give it a try, please report success or failure to emulat...@freebsd.org. Bye, Alexander. Now I might have something to try, but it is very unlikely that I would build a Linux kernel = 2.6.16, especially with new hardware that might need the latest drivers. I will primarily want to run Linux natively rather than under FreeBSD. I think emulators/linux_dist-gentoo-stage3 and emulators/linux_base-gentoo-stage3 must use kernel far beyond 2.6.16. But I think, when chrooting into Linux from FreeBSD, FreeBSD kernel is the one in effect. Not really. The actual thing is, linuxulator is a Linux kernel running as a FreeBSD kernel module. The only thing FreeBSD kernel do is to identify the Linux program and to pass it to the Linux kernel. To the Linux programs inside a GNU chroot enviroment, they think they are running inside a Linux box and actually they are running inside a Linux box. To the Linux programs running under a FreeBSD base, they may identify that the base is not GNU by invoking some external programs like `uname`. However, we can replace their sh with /compat/linux/bin/sh, so that they are blind again. Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux compatibility with more than one Linux installed?
On Tue, 6 Dec 2011 04:54:18 -0600 Zhihao Yuan wrote: Not really. The actual thing is, linuxulator is a Linux kernel running as a FreeBSD kernel module. The only thing FreeBSD kernel do is to identify the Linux program and to pass it to the Linux kernel. To the Linux programs inside a GNU chroot enviroment, they think they are running inside a Linux box and actually they are running inside a Linux box. Are you sure about that? I was under the impression that it was a fairly thin emulation layer on top of the FreeBSD kernel. Has something changed? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux compatibility with more than one Linux installed?
Hi, you don't need to install an old linux kernel. It depends upon the features used by the userland stuff. It is possible to compile glibc to use all features, or to compile it in a way it works on an old kernel too (I have no idea about the details involved). So all depends upon the linux-distribution you use. Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Thomas Mueller mueller6...@bellsouth.net hat geschrieben: The X server has a unix socket somewhere in /tmp. Normally this is used instead of a TCP connection to the localhost. You need to change the DISPLAY env-variable to use a TCP connection, or you need o make the unix socket available to the chrooted linux-env. The linuxulator in FreeBSD is nearly linux 2.6.16 compatible. We lack inotify and epoll support which the 2.6.16 kernel normally supports. If your system does not depend upon inotify, epoll and anything newer than 2.6.16, it should work. If you give it a try, please report success or failure to emulat...@freebsd.org. Bye, Alexander. Now I might have something to try, but it is very unlikely that I would build a Linux kernel = 2.6.16, especially with new hardware that might need the latest drivers. I will primarily want to run Linux natively rather than under FreeBSD. I think emulators/linux_dist-gentoo-stage3 and emulators/linux_base-gentoo-stage3 must use kernel far beyond 2.6.16. But I think, when chrooting into Linux from FreeBSD, FreeBSD kernel is the one in effect. Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux compatibility with more than one Linux installed?
On Tue, Dec 6, 2011 at 6:21 AM, RW rwmailli...@googlemail.com wrote: On Tue, 6 Dec 2011 04:54:18 -0600 Zhihao Yuan wrote: Not really. The actual thing is, linuxulator is a Linux kernel running as a FreeBSD kernel module. The only thing FreeBSD kernel do is to identify the Linux program and to pass it to the Linux kernel. To the Linux programs inside a GNU chroot enviroment, they think they are running inside a Linux box and actually they are running inside a Linux box. Are you sure about that? I was under the impression that it was a fairly thin emulation layer on top of the FreeBSD kernel. Has something changed? To Linux program, there is no emulation layer. This technology should be called extended ELF lookup table, and has nothing to do with emulation. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux compatibility with more than one Linux installed?
On Tue, Dec 6, 2011 at 7:45 AM, RW rwmailli...@googlemail.com wrote: On Tue, 6 Dec 2011 06:29:03 -0600 Zhihao Yuan wrote: On Tue, Dec 6, 2011 at 6:21 AM, RW rwmailli...@googlemail.com wrote: On Tue, 6 Dec 2011 04:54:18 -0600 Zhihao Yuan wrote: Not really. The actual thing is, linuxulator is a Linux kernel running as a FreeBSD kernel module. The only thing FreeBSD kernel do is to identify the Linux program and to pass it to the Linux kernel. To the Linux programs inside a GNU chroot enviroment, they think they are running inside a Linux box and actually they are running inside a Linux box. Are you sure about that? I was under the impression that it was a fairly thin emulation layer on top of the FreeBSD kernel. Has something changed? To Linux program, there is no emulation layer. This technology should be called extended ELF lookup table, and has nothing to do with emulation. It's not emulation in the narrow sense that vmware is emulation and wine isn't, but it certainly is emulation within the normal sense or the word. My dictionary defines emulate as imitate zealously. But what I was getting at was the statement linuxulator is a Linux kernel running as a FreeBSD kernel module which I'm guessing now you didn't mean literally. FreeBSD handbook: http://www.freebsd.org/doc/handbook/linuxemu-advanced.html In effect, there is a Linux kernel in the FreeBSD kernel; the various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, System V IPC, etc... So, if you define a Linux kernel as every thing written by Linus and his followers, then I'm wrong; but if you agree that Android is not GNU but it does run a Linux kernel, then I'm probably right. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: xbmc pvr in ports; update, please test with MythTV too! :)
On 05.12.2011 19:56, Juergen Lock wrote: On Sat, Nov 19, 2011 at 12:37:19PM +0100, Juergen Lock wrote: Hi! So I learned there are actually releases of xbmc pvr already, which means nothing should stop us from committing it to ports too? :) Now I'm wondering if this needs to be repocopied from the xbmc port first since it's kind of a fork... Few patches still apply and I see libreoffice also wasn't repocopied from openoffice, so maybe not? The patch against the xbmc port is here: http://people.freebsd.org/~nox/tmp/xbmc-pvr-ppa-odk55.patch (I just see I haven't added CONFLICTS_INSTALL with xbmc yet, will do that later.) It still seems to work with my older xvdr addon and vdr plugin ports, but maybe I should update those again too before committing: http://people.freebsd.org/~nox/tmp/xbmc-addon-xvdr.shar http://people.freebsd.org/~nox/tmp/vdr-plugin-xvdr.shar Of course everyone is welcome to test... :) (I only tested with vdr, not with mythtv.) Juergen I just updated to the latest release pvr-ppa-odk56: http://people.freebsd.org/~nox/tmp/xbmc-pvr-ppa-odk56.patch It would be nice if someone could verify this works with mythtv too before I commit it... Wow this is a pretty big update. Are you sure this is the way to go with the original multimedia/xbmc port? I would prefer sticking to the upstream version with multimedia/xbmc and have such an custom branch in another port that also reflects this from the name. Do you know about the xbmc-devel port that he maintains on redports? http://redports.org/browser/fneufneu/multimedia -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: xbmc pvr in ports; update, please test with MythTV too! :)
Hi, 2011/12/6 Juergen Lock n...@jelal.kn-bremen.de On Tue, Dec 06, 2011 at 03:15:08PM +0100, Bernhard Froehlich wrote: On 05.12.2011 19:56, Juergen Lock wrote: On Sat, Nov 19, 2011 at 12:37:19PM +0100, Juergen Lock wrote: Hi! So I learned there are actually releases of xbmc pvr already, which means nothing should stop us from committing it to ports too? :) Now I'm wondering if this needs to be repocopied from the xbmc port first since it's kind of a fork... Few patches still apply and I see libreoffice also wasn't repocopied from openoffice, so maybe not? The patch against the xbmc port is here: http://people.freebsd.org/~nox/tmp/xbmc-pvr-ppa-odk55.patch (I just see I haven't added CONFLICTS_INSTALL with xbmc yet, will do that later.) It still seems to work with my older xvdr addon and vdr plugin ports, but maybe I should update those again too before committing: http://people.freebsd.org/~nox/tmp/xbmc-addon-xvdr.shar http://people.freebsd.org/~nox/tmp/vdr-plugin-xvdr.shar Of course everyone is welcome to test... :) (I only tested with vdr, not with mythtv.) Juergen I just updated to the latest release pvr-ppa-odk56: http://people.freebsd.org/~nox/tmp/xbmc-pvr-ppa-odk56.patch It would be nice if someone could verify this works with mythtv too before I commit it... Wow this is a pretty big update. Are you sure this is the way to go with the original multimedia/xbmc port? I would prefer sticking to the upstream version with multimedia/xbmc and have such an custom branch in another port that also reflects this from the name. Oh sorry, yes, I wanted to commit this as multimedia/xbmc-pvr, i.e. the upstream multimedia/xbmc of course should stay in the tree. I guess I didn't make that clear... :( (But that was also the reason for the question about the reopcopy.) Sorry, i don't have the time to maintain and test the pvr branch. two ports with conflict is good for me. Do you know about the xbmc-devel port that he maintains on redports? http://redports.org/browser/fneufneu/multimedia I haven't looked at that yet but I guess it doesn't have pvr functionality that I was after? (i.e. `Live TV' in the main menu etc.) every month, i update the xbmc-devel to be ready for the 11 release (soon !) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
binutils-2.22: ld and --copy-dt-needed-entries
Just for your information. It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries behavior, and so explicit --copy-dt-needed-entries is now needed where the previous default behavior is relied upon. A short excerpt from the man page for your convenience: This option also has an effect on the resolution of symbols in dynamic libraries. With --copy-dt-needed-entries dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With the default setting however the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux compatibility with more than one Linux installed?
Well, I'm wrong. I read in effect as in fact... -- Zhihao Yuan On Dec 6, 2011 9:33 AM, RW rwmailli...@googlemail.com wrote: On Tue, 6 Dec 2011 08:04:59 -0600 Zhihao Yuan wrote: On Tue, Dec 6, 2011 at 7:45 AM, RW rwmailli...@googlemail.com wrote: But what I was getting at was the statement linuxulator is a Linux kernel running as a FreeBSD kernel module which I'm guessing now you didn't mean literally. FreeBSD handbook: http://www.freebsd.org/doc/handbook/linuxemu-advanced.html In effect, there is a Linux kernel in the FreeBSD kernel; ... Clearly the author of that article doesn't agree with you or he wouldn't have written In effect. If your statement had been: linuxulator is effectively a Linux kernel running as a FreeBSD kernel, then it wouldn't have been plain wrong. So, if you define a Linux kernel as every thing written by Linus and his followers, then I'm wrong; but if you agree that Android is not GNU but it does run a Linux kernel, then I'm probably right. Android is based on fork of Linux, it contains real Linux code. All you could argue from that is that the linuxulator could be called Linux if it were based on Linux code. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: binutils-2.22: ld and --copy-dt-needed-entries
On 6.12.2011 17:48, Andriy Gapon wrote: Just for your information. It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries behavior, and so explicit --copy-dt-needed-entries is now needed where the previous default behavior is relied upon. A short excerpt from the man page for your convenience: This option also has an effect on the resolution of symbols in dynamic libraries. With --copy-dt-needed-entries dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With the default setting however the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols. What do we do with this? We can go back, patch to behave as before or to continue. Are there any serious complaints? -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
multimedia/transcode
Hi, transcode is already it 1.1.7 and allegedly features a better video stabilizing plugin. Our version in ports is still at 1.1.5. Could you please update the port? The distfile is here: https://bitbucket.org/france/transcode-tcforge/downloads Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: binutils-2.22: ld and --copy-dt-needed-entries
on 06/12/2011 23:24 Martin Matuska said the following:
On 6.12.2011 17:48, Andriy Gapon wrote:
Just for your information.
It seems that ld from binutils-2.22 by default has
--no-copy-dt-needed-entries
behavior, and so explicit --copy-dt-needed-entries is now needed where the
previous default behavior is relied upon.
A short excerpt from the man page for your convenience:
This option also has an effect on the resolution of symbols in
dynamic libraries. With --copy-dt-needed-entries dynamic libraries
mentioned on the command line will be recursively searched,
following their DT_NEEDED tags to other libraries, in order to
resolve symbols required by the output binary. With the default
setting however the searching of dynamic libraries that follow it
will stop with the dynamic library itself. No DT_NEEDED links will
be traversed to resolve symbols.
What do we do with this?
We can go back, patch to behave as before or to continue.
Are there any serious complaints?
I am not sure. Eventually all upstreams of our ports will have to deal with
this. So far I've encountered only one problematic port (gegl) that links a
binary with -lglib-2.0 expecting that a required -liconv dependency would be
automatically picked up via DT_NEEDED. libglib-2.0.so indeed has a DT_NEEDED
entry for libiconv.so. But this dependency is not explicitly advertised via
pkg-config metadata:
$ fgrep -i Libs /usr/local/libdata/pkgconfig/glib-2.0.pc
Libs: -L${libdir} -lglib-2.0
Libs.private: -liconv
So there could be other issues related to this in the future.
Perhaps this is actually an issue with glib, maybe it should have -liconv in
Libs. I am not really knowledgeable about his stuff.
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: binutils-2.22: ld and --copy-dt-needed-entries
On Tue, Dec 6, 2011 at 23:41, Andriy Gapon a...@freebsd.org wrote:
on 06/12/2011 23:24 Martin Matuska said the following:
On 6.12.2011 17:48, Andriy Gapon wrote:
Just for your information.
It seems that ld from binutils-2.22 by default has
--no-copy-dt-needed-entries
behavior, and so explicit --copy-dt-needed-entries is now needed where the
previous default behavior is relied upon.
A short excerpt from the man page for your convenience:
This option also has an effect on the resolution of symbols in
dynamic libraries. With --copy-dt-needed-entries dynamic libraries
mentioned on the command line will be recursively searched,
following their DT_NEEDED tags to other libraries, in order to
resolve symbols required by the output binary. With the default
setting however the searching of dynamic libraries that follow it
will stop with the dynamic library itself. No DT_NEEDED links will
be traversed to resolve symbols.
What do we do with this?
We can go back, patch to behave as before or to continue.
Are there any serious complaints?
I am not sure. Eventually all upstreams of our ports will have to deal with
this. So far I've encountered only one problematic port (gegl) that links a
binary with -lglib-2.0 expecting that a required -liconv dependency would be
automatically picked up via DT_NEEDED. libglib-2.0.so indeed has a DT_NEEDED
entry for libiconv.so. But this dependency is not explicitly advertised via
pkg-config metadata:
$ fgrep -i Libs /usr/local/libdata/pkgconfig/glib-2.0.pc
Libs: -L${libdir} -lglib-2.0
Libs.private: -liconv
So there could be other issues related to this in the future.
Perhaps this is actually an issue with glib, maybe it should have -liconv in
Libs. I am not really knowledgeable about his stuff.
As far, as I understand the
http://lists.debian.org/debian-devel-announce/2011/02/msg00011.html ,
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition ,
http://old.nabble.com/Make-no-copy-dt-needed-default--td32272377.html ,
correctly
1. upstreams (e.g. Glib) had a pretty much time for test this change.
2. If I just use Glib (for example), then all Glib's iconv-related
stuffs will continue to work, I don't need to explicitly add -liconv.
All that fail if I use iconv_open() (for example) directly and
(bypassing Glib) and rely on Glib to load libiconv as side-effect. Of
courcse, it would be quite wrong from my side because existence of
libconv as an Glib charset conversion engine is an implementation
detail that may change at the some day or just because of different
configuration options. Just like GnuTLS swtiched from libgcrypt to
libnettle.
3. Of course, something may fail, but I would not to expect a big
amount of failures (due to the fact that major Linux distros already
there)
--
Andrew W. Nosenko andrew.w.nose...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: multimedia/transcode
On 12/06/11 16:03, C. P. Ghost wrote: Hi, transcode is already it 1.1.7 and allegedly features a better video stabilizing plugin. Our version in ports is still at 1.1.5. Could you please update the port? The distfile is here: https://bitbucket.org/france/transcode-tcforge/downloads Thanks, -cpghost. I'll look into this during the weekend. Thanks, Naram ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port: multimedia/handbrake
On Tue, Nov 29, 2011 at 4:43 AM, Chris Rees cr...@freebsd.org wrote: On 29 November 2011 11:21, q00...@googlemail.com wrote: Hi, the version of HandBrake in the ports is outdated and can not be build under amd64. With the patches from http://www.bpsw.biz/handbrake-freebsd/ it is possible to build the current version (0.9.5) on amd64 (8.1 and 8.2 tested). I assume that this also works on i386, but did not test it. Can the Patches be integrated into the port please? Direct URL: http://www.bpsw.biz/handbrake-freebsd/download/handbrake- freebsd-0.9.5.tgz Disclosure: I did not write them. I'll have a look later today, if no-one beats me to it. For future reference, patches sometimes get 'lost' in this mailing list, better to send a PR. http://www.freebsd.org/send-pr.html I have been working on getting Handbrake 0.9.5 to build on FreeBSD for some time. I had resolved a number of issues, but had no luck with some assembler issues in the ffmpeg portion. I am working on converting this work to a FreeBSD port Looks straight-forward, but no promises. I'll report on success (or failure) and submit a PR to get the port updated it that appears to be appropriate. I have maintained several ports over the years and still maintain one, so I have some experience with porting, but will hardly claim to be an expert. I suspect you have more expertise than I do, Chris, so feel free to take it over. Thanks for getting this out so others can use it! -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port: multimedia/handbrake
On Tue, Dec 6, 2011 at 11:23 PM, Kevin Oberman kob6...@gmail.com wrote: I have been working on getting Handbrake 0.9.5 to build on FreeBSD for some time. I had resolved a number of issues, but had no luck with some assembler issues in the ffmpeg portion. Yes, I got stuck at the same spot. Then I found this: http://lists.freebsd.org/pipermail/freebsd-ports/2011-July/068940.html It's been working for me, but it's a bit out of date now. -- Adam Vande More ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
