Re: Can't get gvim working
On 05/08/2012 00:12, Doug Barton wrote: On 08/04/2012 14:56, David Demelier wrote: I finally found the problem: at the configure target see, checking for GTK - version = 2.2.0... Package glproto was not found in the pkg-config search path. Perhaps you should add the directory containing `glproto.pc' to the PKG_CONFIG_PATH environment variable No package 'glproto' found no x11/glproto was not installed, I think we could add a dependency on it. Seems to apply only to the gnome define, as I can build and run gvim without it. David, what do you think of the attached? Doug I would rather place in the WITH_GTK2 conditional, since gtk2 requires glproto too. Cheers, -- David Demelier ___ 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: Can't get gvim working
On 08/05/2012 00:18, David Demelier wrote: On 05/08/2012 00:12, Doug Barton wrote: On 08/04/2012 14:56, David Demelier wrote: I finally found the problem: at the configure target see, checking for GTK - version = 2.2.0... Package glproto was not found in the pkg-config search path. Perhaps you should add the directory containing `glproto.pc' to the PKG_CONFIG_PATH environment variable No package 'glproto' found no x11/glproto was not installed, I think we could add a dependency on it. Seems to apply only to the gnome define, as I can build and run gvim without it. David, what do you think of the attached? Doug I would rather place in the WITH_GTK2 conditional, since gtk2 requires glproto too. ... that was the point of my reporting that with just gtk2 glproto is *not* needed. :) Why do you think it is? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: Can't get gvim working
On 05/08/2012 11:01, Doug Barton wrote: On 08/05/2012 00:18, David Demelier wrote: On 05/08/2012 00:12, Doug Barton wrote: On 08/04/2012 14:56, David Demelier wrote: I finally found the problem: at the configure target see, checking for GTK - version = 2.2.0... Package glproto was not found in the pkg-config search path. Perhaps you should add the directory containing `glproto.pc' to the PKG_CONFIG_PATH environment variable No package 'glproto' found no x11/glproto was not installed, I think we could add a dependency on it. Seems to apply only to the gnome define, as I can build and run gvim without it. David, what do you think of the attached? Doug I would rather place in the WITH_GTK2 conditional, since gtk2 requires glproto too. ... that was the point of my reporting that with just gtk2 glproto is *not* needed. :) Why do you think it is? Doug Because the check of Gtk2 fails if it is not enabled, thus no gtk2 gui will be enabled the same error as my first post. -- David Demelier ___ 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: [CFT] [bsd.port.mk] ports ccache build support
On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: On 4 August 2012 15:21, RW rwmailli...@googlemail.com wrote: On Sat, 04 Aug 2012 09:42:39 -0500 Bryan Drewery wrote: Having a default ccache directory in the makefile that's different from the default documented in the ccache man page seems needlessly confusing to me. +1 for /var/cache And since large root file-systems seem to be increasingly popular, /root/.ccache may seem reasonable, and people may run cache -M on that. remember that its possible to build as a non-root user, but install as root, or similar. Using $HOME for any aspect of the build isn't a good idea. Why isn't it? In that scenario /var/cache wouldn't be writable. ___ 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
Request: py-mnemosyne 2
Hi everyone mnemosyne 2.0.1 is out for a while. I was wandering, if there is any hope to have it updated in ports. Thank you Marek ___ 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
Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
Hi kib, -current, seems we have a segfault in rtld when updating the multimedia/vlc port from the version currently in ports to the 2.0.3 CFT version from here: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch (If you test the LIVEMEDIA knob you also need this update: http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch ) In article 20120804110952.4f3a9...@ernst.jennejohn.org you write: On Fri, 3 Aug 2012 18:36:33 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: On Thu, 2 Aug 2012 22:56:26 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: [trimmed irrelevant content] Ok I added that check: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch Enjoy, :) AMD64 on HEAD. I always get this error, no matter which patch I use: GEN../modules/plugins.dat gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core dumped) gmake[2]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' gmake: *** [all] Error 2 *** [do-build] Error code 1 I get exactly the same error with CURRENT amd64. Hm how old are both your installed src and ports? You two are the first to report this and I just tried to reproduce it on a head checkout from May 13 and ports from June 18, and couldn't. I update the ports and source trees almost every day. I do not install new ports binaries unless absolutely necessary, so the ports binaries are pretty much rather old. Just installed a new world/kernel today (updated yesterdya), r239006. BTW, mplayer from ports does not build with liveMedia-20120404 ... Stop in /usr/ports/multimedia/vlc. *** [build] Error code 1 and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. May be because I have a mix of old and new dependencies, although the vlc port never tries to update any of them. Well ports never update dependencies themselves, you need to use tools like portmaster for that. I avoid using tools whenever possible. Maybe I will have to try portmaster, but I dread seeing 50 ports updated just because I want to update one port. I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the result. gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... (gdb) r ../modules/ Starting program: /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ [New LWP 100125] [New Thread 802406400 (LWP 100125/vlc-cache-gen)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 (gdb) bt #0 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 #1 0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 #2 0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 #3 0x00080060911b in symlook_default () from /libexec/ld-elf.so.1 #4 0x00080060939d in find_symdef () from /libexec/ld-elf.so.1 #5 0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 #6 0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 #7 0x0008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 #8 0x000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 #9 0x000800affe95 in module_Load (p_this=0x80244c198, psz_file=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, p_handle=0x7fffd180, lazy=true) at posix/plugin.c:62 #10 0x000800adef4b in module_InitDynamic (obj=0x80244c198, path=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, fast=true) at modules/bank.c:536 #11 0x000800adede2 in AllocatePluginFile (bank=0x7fffd490, abspath=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, relpath=0x802472b80 codec/.libs/libfluidsynth_plugin.so, st=0x7fffd210) at modules/bank.c:479 #12 0x000800adeca3 in AllocatePluginDir (bank=0x7fffd490, maxdepth=2, absdir=0x802472b00 ../modules//codec/.libs, reldir=0x802472a80 codec/.libs) at modules/bank.c:440 #13 0x000800adecd7 in AllocatePluginDir (bank=0x7fffd490, maxdepth=3, absdir=0x802472a00 ../modules//codec, reldir=0x8024704f0 codec) at modules/bank.c:444 #14 0x000800adecd7 in AllocatePluginDir (bank=0x7fffd490, maxdepth=4,
Re: php53-pdo_mysql fail with MYSQLND
Hello, you are right. pkg_deinstall php53-pdo_mysql and make install works without problems. Regards, Michael Am 05.08.12 02:32, schrieb Panagiotis Christias: On 3/8/2012 23:44, Michael Ranner wrote: Hello! I have trouble with upgrading php53-pdo_mysql (5.3.14 to 5.3.15) on several systems, where I try to upgrade with portmaser. Build works without option MYSQLND but breaks with MYSQLND. Probably this have something to do with ports/169959. poudriere builds php53-pdo_mysql without problems from scratch, but I have no idea why it breaks ob my production systems. Hello, I had the same problem and managed to get around it by deinstalling php53-pdo_mysql 5.3.14 and then installing php53-pdo_mysql 5.3.15. MYSQLND was not defined, but in my case the problem seemed to be the definition #define HAVE_MYSQL_STMT_PREPARE 1 in /usr/local/include/php/ext/pdo_mysql/config.h of the php53-pdo_mysql 5.3.14 installation. Regards, Panagiotis -- Mit freundlichen Grüßen Ing. Michael Ranner GSM: +43 676 4155044 Mail: mich...@ranner.eu WWW: http://www.azedo.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: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: Hi kib, -current, seems we have a segfault in rtld when updating the multimedia/vlc port from the version currently in ports to the 2.0.3 CFT version from here: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch (If you test the LIVEMEDIA knob you also need this update: http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch ) Please do two things. 1. Provide me the output of readelf -a for the module that was loaded. 2. Recompile rtld with debug symbols and redo the build to get the useful backtrace from core: cd /usr/src/libexec/rtld-elf make clean make all install DEBUG_FLAGS=-g In article 20120804110952.4f3a9...@ernst.jennejohn.org you write: On Fri, 3 Aug 2012 18:36:33 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: On Thu, 2 Aug 2012 22:56:26 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: [trimmed irrelevant content] Ok I added that check: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch Enjoy, :) AMD64 on HEAD. I always get this error, no matter which patch I use: GEN../modules/plugins.dat gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core dumped) gmake[2]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' gmake: *** [all] Error 2 *** [do-build] Error code 1 I get exactly the same error with CURRENT amd64. Hm how old are both your installed src and ports? You two are the first to report this and I just tried to reproduce it on a head checkout from May 13 and ports from June 18, and couldn't. I update the ports and source trees almost every day. I do not install new ports binaries unless absolutely necessary, so the ports binaries are pretty much rather old. Just installed a new world/kernel today (updated yesterdya), r239006. BTW, mplayer from ports does not build with liveMedia-20120404 ... Stop in /usr/ports/multimedia/vlc. *** [build] Error code 1 and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. May be because I have a mix of old and new dependencies, although the vlc port never tries to update any of them. Well ports never update dependencies themselves, you need to use tools like portmaster for that. I avoid using tools whenever possible. Maybe I will have to try portmaster, but I dread seeing 50 ports updated just because I want to update one port. I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the result. gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... (gdb) r ../modules/ Starting program: /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ [New LWP 100125] [New Thread 802406400 (LWP 100125/vlc-cache-gen)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 (gdb) bt #0 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 #1 0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 #2 0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 #3 0x00080060911b in symlook_default () from /libexec/ld-elf.so.1 #4 0x00080060939d in find_symdef () from /libexec/ld-elf.so.1 #5 0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 #6 0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 #7 0x0008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 #8 0x000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 #9 0x000800affe95 in module_Load (p_this=0x80244c198, psz_file=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, p_handle=0x7fffd180, lazy=true) at posix/plugin.c:62 #10 0x000800adef4b in module_InitDynamic (obj=0x80244c198, path=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, fast=true) at modules/bank.c:536 #11 0x000800adede2 in AllocatePluginFile (bank=0x7fffd490, abspath=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, relpath=0x802472b80 codec/.libs/libfluidsynth_plugin.so, st=0x7fffd210) at
Re: [CFT] [bsd.port.mk] ports ccache build support
On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote: On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: Why isn't it? In that scenario /var/cache wouldn't be writable. IMHO the directories used by the ports system should be predictable and static. Which user you happen to be shouldn't affect that choice. -- Eitan Adler ___ 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: [CFT] [bsd.port.mk] ports ccache build support
On Sun, Aug 5, 2012 at 7:18 PM, Eitan Adler li...@eitanadler.com wrote: On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote: On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: Why isn't it? In that scenario /var/cache wouldn't be writable. IMHO the directories used by the ports system should be predictable and static. Which user you happen to be shouldn't affect that choice. Regardless of what the shared directory is the problem of setting permissions so that multiple users can share the ccache directory is something that the ports system shouldn't try to solve. Leave it to the admin of the system. ___ 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: [CFT] [bsd.port.mk] ports ccache build support
On Sun, Aug 5, 2012 at 11:40 AM, Kimmo Paasiala kpaas...@gmail.com wrote: On Sun, Aug 5, 2012 at 7:18 PM, Eitan Adler li...@eitanadler.com wrote: On 5 August 2012 04:15, RW rwmailli...@googlemail.com wrote: On Sat, 4 Aug 2012 17:38:44 -0700 Eitan Adler wrote: Why isn't it? In that scenario /var/cache wouldn't be writable. IMHO the directories used by the ports system should be predictable and static. Which user you happen to be shouldn't affect that choice. Regardless of what the shared directory is the problem of setting permissions so that multiple users can share the ccache directory is something that the ports system shouldn't try to solve. Leave it to the admin of the system. I agree. The document in the ccache port is pretty clear and it's not hard to follow. Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: [CFT] editors/emacs to 24.1
On Fri, 3 Aug 2012, the wise Ashish SHUKLA wrote: Sorry about the problem. Could you please mention the error messages (if any you're getting) ? It seems that emacs 24.1 core dumps only with dbus enabled: ... Fatal error (11)Segmentation fault (core dumped) ... With dbus disabled (and gconf/gsettings too) emacs works, but when trying to open a file it crashes: ... (emacs:90186): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.AfcVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/local/libexec/gvfs-afc-volume-monitor exited with status 1 Segmentation fault (core dumped) ... So it seems to me that emacs needs dbus? Regards, Marco -- A doctor calls his patient to give him the results of his tests. I have some bad news, says the doctor, and some worse news. The bad news is that you only have six weeks to live. Oh, no, says the patient. What could possibly be worse than that? Well, the doctor replies, I've been trying to reach you since last Monday. ___ 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: Jenkins+FreeBSD handbooks
On Fri, Aug 3, 2012 at 9:33 PM, Marin Atanasov Nikolov dna...@gmail.com wrote: On Fri, Aug 3, 2012 at 10:14 PM, Bernhard Fröhlich de...@freebsd.org wrote: Hello Bernhard, Thanks a lot for that tutorials. They look very interesting and I was always curious how much work it would have been to implement something like redports.org on top of Jenkins. But obviously my decision was correct that jenkins would not fit in such a situation. Could you clarify a bit more why you think Jenkins does not fit well there? I don't know how redports.org is designed and how it scales, but with Jenkins it's quite easy to create a package build farm for distributed building. Redports is a public compile testing environment for FreeBSD ports. So like Ports Tinderbox but with a nice multiuser GUI, cluster functionality for scaling and an own Subversion tree for the users to commit their ports to. Before I decided to write the code myself I had a closer look at Bitten and Jenkins. Both could be made into what redports is now but they all have their weak spots. Jenkins GUI looks very cluttered and is quite hard to understand if you just want to manually schedule a few new jobs for your ports as Joe Average. It's also quite hard to understand and complex as a developer and administrator so I was concerned that fixing it if it breaks is non trivial. Not to talk about all the special customizations that we need which would require me to write extensions in Java and understand how all that jenkins internals work. Bitten looked simpler and less complex but would also work for standard things but it got me on the right track to use Trac as webinterface and just extend Trac with a custom plugin that includes a few simple pages to have an overview of jobs and add new ones. Jenkins comes with lots of ready-to-use plugins as well, which makes it easier to integrate a particular thing easier as well and not re-invent the wheel. Yeah that is nice and there is almost everything that you can think of but none of them did what I needed. A simple web interface for average people that don't want to learn Jenkins internals and is easily customizable. Probably there is a plugin for that but I didn't find it. Writing some glue code around tinderbox to schedule new jobs, checkout repositories and such stuff is custom code anyway. A more suitable place for jenkins would be automatic building our doc tree on every commit. But I don't know if that doesn't already exist. Yep, that's one of the things we could use Jenkins for, but I would say we could use it for lots of other stuff as well :) I'm sure we could. Examples? -- 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: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
On Sun, Aug 05, 2012 at 07:13:53PM +0300, Konstantin Belousov wrote: On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: Hi kib, -current, seems we have a segfault in rtld when updating the multimedia/vlc port from the version currently in ports to the 2.0.3 CFT version from here: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch (If you test the LIVEMEDIA knob you also need this update: http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch ) Please do two things. 1. Provide me the output of readelf -a for the module that was loaded. 2. Recompile rtld with debug symbols and redo the build to get the useful backtrace from core: cd /usr/src/libexec/rtld-elf make clean make all install DEBUG_FLAGS=-g Ok, someone who got the crash will have to do this as I couln't reproduce it here (sorry forgot to say...) Thanx, :) Juergen In article 20120804110952.4f3a9...@ernst.jennejohn.org you write: On Fri, 3 Aug 2012 18:36:33 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: On Thu, 2 Aug 2012 22:56:26 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: [trimmed irrelevant content] Ok I added that check: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch Enjoy, :) AMD64 on HEAD. I always get this error, no matter which patch I use: GEN../modules/plugins.dat gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core dumped) gmake[2]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' gmake: *** [all] Error 2 *** [do-build] Error code 1 I get exactly the same error with CURRENT amd64. Hm how old are both your installed src and ports? You two are the first to report this and I just tried to reproduce it on a head checkout from May 13 and ports from June 18, and couldn't. I update the ports and source trees almost every day. I do not install new ports binaries unless absolutely necessary, so the ports binaries are pretty much rather old. Just installed a new world/kernel today (updated yesterdya), r239006. BTW, mplayer from ports does not build with liveMedia-20120404 ... Stop in /usr/ports/multimedia/vlc. *** [build] Error code 1 and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. May be because I have a mix of old and new dependencies, although the vlc port never tries to update any of them. Well ports never update dependencies themselves, you need to use tools like portmaster for that. I avoid using tools whenever possible. Maybe I will have to try portmaster, but I dread seeing 50 ports updated just because I want to update one port. I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the result. gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... (gdb) r ../modules/ Starting program: /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ [New LWP 100125] [New Thread 802406400 (LWP 100125/vlc-cache-gen)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 (gdb) bt #0 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 #1 0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 #2 0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 #3 0x00080060911b in symlook_default () from /libexec/ld-elf.so.1 #4 0x00080060939d in find_symdef () from /libexec/ld-elf.so.1 #5 0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 #6 0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 #7 0x0008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 #8 0x000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 #9 0x000800affe95 in module_Load (p_this=0x80244c198, psz_file=0x802472c00 ../modules//codec/.libs/libfluidsynth_plugin.so, p_handle=0x7fffd180, lazy=true) at posix/plugin.c:62 #10 0x000800adef4b in module_InitDynamic (obj=0x80244c198, path=0x802472c00
Re: [CFT] editors/emacs to 24.1
On Sun, 5 Aug 2012 19:28:42 +0200 (CEST), Marco Beishuizen mb...@xs4all.nl said: On Fri, 3 Aug 2012, the wise Ashish SHUKLA wrote: Sorry about the problem. Could you please mention the error messages (if any you're getting) ? It seems that emacs 24.1 core dumps only with dbus enabled: ... Fatal error (11)Segmentation fault (core dumped) ... With dbus disabled (and gconf/gsettings too) emacs works, but when trying to open a file it crashes: ... (emacs:90186): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.AfcVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/local/libexec/gvfs-afc-volume-monitor exited with status 1 Segmentation fault (core dumped) ... So it seems to me that emacs needs dbus? Does emacs -Q crash for you as well? Thanks -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 Sent from my Emacs pgpFkWNWxXI1L.pgp Description: PGP signature
Re: [CFT] editors/emacs to 24.1
On Sun, 5 Aug 2012, the wise Ashish SHUKLA wrote: Does emacs -Q crash for you as well? Yes, same error messages. Regards, Marco -- Don't relax! It's only your tension that's holding you together. ___ 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: [CFT] editors/emacs to 24.1
On Fri, 03 Aug 2012 23:06:29 +0530, ash...@freebsd.org (Ashish SHUKLA) said: On Fri, 3 Aug 2012 19:19:02 +0200 (CEST), Marco Beishuizen mb...@xs4all.nl said: On Fri, 3 Aug 2012, the wise Ashish SHUKLA wrote: I use following, and it seems to work fine for me: --8---cut here---start-8--- #!/bin/sh xrdb ~/.Xdefaults xmodmap ~/.Xmodmap gnome-screensaver exec dbus-launch --exit-with-session ck-launch-session fluxbox 21 $HOME/.xsession-errors --8---cut here---end---8--- FTR, my Emacs is compiled with GTK3/DBUS/GCONF options. Could you try it? I've tried all this but no differences. Still crashes and lockups. Regards, Marco Sorry about the problem. Could you please mention the error messages (if any you're getting) ? Also, could you try compiling it with DEBUG symbols, if not already using, i.e. % sudo make -C /usr/ports/editors/emacs -DWITH_DEBUG build deinstall package clean If it dumps core, then you can then inspect core using gdb, and send the backtrace: % gdb $(which emacs) (gdb) core-file emacs.core (gdb) bt full Hi Marco, Could you provide output of those () ? Thanks -- Ashish SHUKLA “Any priest or shaman must be presumed guilty until proved innocent.” (Robert A. Heinlein, 1973) Sent from my Emacs pgpMT9a0few3b.pgp Description: PGP signature
Re: Can't get gvim working
On 08/05/2012 03:05, David Demelier wrote: On 05/08/2012 11:01, Doug Barton wrote: On 08/05/2012 00:18, David Demelier wrote: On 05/08/2012 00:12, Doug Barton wrote: On 08/04/2012 14:56, David Demelier wrote: I finally found the problem: at the configure target see, checking for GTK - version = 2.2.0... Package glproto was not found in the pkg-config search path. Perhaps you should add the directory containing `glproto.pc' to the PKG_CONFIG_PATH environment variable No package 'glproto' found no x11/glproto was not installed, I think we could add a dependency on it. Seems to apply only to the gnome define, as I can build and run gvim without it. David, what do you think of the attached? Doug I would rather place in the WITH_GTK2 conditional, since gtk2 requires glproto too. ... that was the point of my reporting that with just gtk2 glproto is *not* needed. :) Why do you think it is? Doug Because the check of Gtk2 fails if it is not enabled, thus no gtk2 gui will be enabled the same error as my first post. Ok, let me try again. :) I don't have glproto installed. I have the gtk GUI option enabled. I can configure, build, and run gvim just fine without glproto; with no errors. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: [CFT] [bsd.port.mk] ports ccache build support
Bryan Drewery bdrew...@freebsd.org writes:
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
Why not ${.OBJDIR}/ccache? This avoids one big port taking away all
allocated space for itself unless --max-size is raised.
Also, I have /usr/obj - /nonexistent symlink. Anything that doesn't
respect MAKEOBJDIRPREFIX is bogus.
___
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
CDE released as open source
As spotted in OSNews.com, CDE has been released under LGPL on sourceforge: http://www.cdesktopenv.org/ The linux port is still considered alpha quality. CDE brings me some (not too good) memories as it managed to make some supposedly big servers look really slow but it will certainly be a pleasure to have it as another option in FreeBSD! cheers, Pedro. ___ 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: [CFT] [bsd.port.mk] ports ccache build support
On 08/05/2012 19:47, Jan Beich wrote:
Bryan Drewery bdrew...@freebsd.org writes:
The cache directory CCACHE_DIR defaults to /usr/obj/ccache
Why not ${.OBJDIR}/ccache? This avoids one big port taking away all
allocated space for itself unless --max-size is raised.
Also, I have /usr/obj - /nonexistent symlink. Anything that doesn't
respect MAKEOBJDIRPREFIX is bogus.
Bryan's proposal is for ports. /usr/obj is for things in the base.
The equivalent to MAKEOBJDIRPREFIX in ports is WRKDIRPREFIX, but IMO the
ccache cache should be independent of either.
Personally I don't see why we would want to change the defaults here at
all. There are 2 possibilities ... either the user has customized the
location, in which case we shouldn't mess with it. Or, they haven't, in
which case if the regular default for the port is good, it should be
used. If it isn't, it should be fixed for all users.
Doug
--
I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
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: [CFT] [bsd.port.mk] ports ccache build support
On 8/4/2012 7:38 PM, Eitan Adler wrote: On 4 August 2012 15:21, RW rwmailli...@googlemail.com wrote: On Sat, 04 Aug 2012 09:42:39 -0500 Bryan Drewery wrote: Having a default ccache directory in the makefile that's different from the default documented in the ccache man page seems needlessly confusing to me. +1 for /var/cache And since large root file-systems seem to be increasingly popular, /root/.ccache may seem reasonable, and people may run cache -M on that. remember that its possible to build as a non-root user, but install as root, or similar. Using $HOME for any aspect of the build isn't a good idea. I can see both arguments here. non-root building suggests $HOME/.ccache. This has the benefit of having ccache(1) just work when configuring. A downside of possibly duplicating the cache for some users. pkgng is storing cache files in /var/cache/pkg. This is not listed in hier(7) yet, but probably should be added. Given that, /var/cache/ccache makes sense as well. I still am concerned that adding a default 1gb sized cache into /var is not a good idea. Another downside is having to define CCACHE_DIR to run ccache(1) I actually had used /var/cache in my initial patch, but changed to /usr/obj since /var can be so small. On my own systems I have a mess of symlinks to fix my own indecision on the matter. /root/.ccache - /var/cache/ccache - /usr/ccache I'm starting to lean towards sticking to the default of $HOME/.ccache as well as it may be more safe and less confusing to use with ccache(1). The user can always override. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ 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: lang/gcc46
On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: lang/gcc and lang/gcc46 should be fully compatible, without rebuilds necessary. Only when lang/gcc is going to move to GCC 4.7 later this year would I consider that. IMO this highlights the issue that unversioned instances of ports that really need versioning (like gcc) are a bad idea. It's much better for users to be able to tie their installations to a particular version, and then only update when they need to. The fact that someday in the future users who innocently upgrade lang/gcc will suddenly find that everything relying on libgcc at runtime is now broken pretty much speaks for itself. The fact that I would consider that, was not supposed to imply breakage. :-) I was more thinking better optimization and other benefits. I'm not asking you to agree with me that the current situation is broken. I'm merely pointing out that it *is* broken, and pointing out solid, non-broken examples that we already have. In my day job, we have been doing upgrades from GCC 4.x to GCC 4.x+y run-times quite successfully and without any breakage more than once. And we've got many, quite many, users. Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. In other words, if there is a challenge it's not GCC per se, more our packaging of it (and some work Bapt is doing on the packaging infrastructure should help with that). I don't know of any magic solutions in the works that will solve the separation of libgcc from the compiler. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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
