Re: New X.Org
On 04/23/12 09:37, Warren Block wrote: On Mon, 23 Apr 2012, matt wrote: On 04/23/12 05:59, Warren Block wrote: On Mon, 23 Apr 2012, Andrea Venturoli wrote: I have a Radeon card, so, does this mean I will get xorg-server? Any way to get 1.10? Any advantage into this? A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa 7.11. So far there are no Firefox title bar artifacts like there were occasionally with the earlier version. Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, xorg-server, xf86-input-*, xf86-video-*, and... a few other things I should have taken notes on. Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus Errors at the same address whenever certain applications are launched. Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal, ioquake3, compiz I just completed recompiling all ports dependent on libGL with no luck. I had WITHOUT_NOUVEAU in make.conf at the same time as WITH_NEW_XORG, is that the problem? Does this sound like an Xorg problem or a ports/ld problem? I also did 'portmaster driconf', which rebuilt libglut and libGLU. Run pkg_libchk from sysutils/bsdadminscripts to check for missing libraries. I rebuilt most ports, the rest are rebuilding now. The problem can be excluded by not running my normal xinitrc, however I do think this may be either an X or base system bug? Test case for creating this involves starting with my normal xinitrc, desktop appears, then launching Thunar. Closing a window also causes the crash. Here is a complete backtrace...can anyone make any sense of this? Is this related to the libthr.so.3 issues recently on CURRENT? Program received signal SIGBUS, Bus error. 0x000803bc8bb2 in glxGetScreen () from /usr/local/lib/xorg/modules/extensions/libglx.so (gdb) Continuing. Program received signal SIGABRT, Aborted. 0x000803254bbc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000803254bbc in thr_kill () from /lib/libc.so.7 #1 0x0008032fee9b in abort () from /lib/libc.so.7 #2 0x0046ceff in OsAbort () #3 0x00479bfc in ddxGiveUp () #4 0x000a in ?? () #5 0x7d25c10fe5bd6725 in ?? () #6 0x00593830 in ?? () #7 0x004694ee in LogSetParameter () #8 0x00469743 in FatalError () #9 0x0046a703 in OsLookupColor () #10 0x01116c00 in ?? () #11 0x7d25c10fe5bd6725 in ?? () #12 0x7fffd3a0 in ?? () #13 0x0100e400 in ?? () #14 0x7fffd780 in ?? () #15 0x000802fdf1be in pthread_sigmask () from /lib/libthr.so.3 #16 0x000802fdf34b in pthread_sigmask () from /lib/libthr.so.3 #17 0x7043 in ?? () #18 0x000802fdf270 in pthread_sigmask () from /lib/libthr.so.3 #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? () ---Type return to continue, or q return to quit--- #23 0x5a5a5a5a5a5a5a5a in ?? () #24 0x03380100 in ?? () #25 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 #26 0x0001 in ?? () #27 0x in ?? () #28 0x000a8008 in ?? () #29 0x0118 in ?? () #30 0x0001 in ?? () #31 0x0080ccf8 in screenInfo () #32 0x04c00dc0 in ?? () #33 0x04c97000 in ?? () #34 0x03380100 in ?? () #35 0x0080ccc0 in ScreenSaverBlanking () #36 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 #37 0x008026c0 in RegionEmptyBox () #38 0x001b00130009 in ?? () #39 0x in ?? () #40 0x003b003b0001 in ?? () #41 0x in ?? () #42 0x000803bc8bb2 in glxGetScreen () from /usr/local/lib/xorg/modules/extensions/libglx.so #43 0x0043 in ?? () #44 0x00013202 in ?? () ---Type return to continue, or q return to quit--- #45 0x7fffd850 in ?? () #46 0x003b in ?? () #47 0x0320 in ?? () #48 0x00010002 in ?? () #49 0x00020002 in ?? () #50 0x037f in ?? () #51 0x in ?? () #52 0x in ?? () #53 0x00021fa0 in ?? () #54 0x68741582 in ?? () #55 0x in ?? () #56 0x in ?? () #57 0x in ?? () #58 0x in ?? () #59 0x in ?? () #60 0x in ?? () #61 0x in ?? () #62 0x in ?? () #63 0x in ?? () #64 0x191b in ?? () #65 0x in ?? () #66 0x in ?? () #67 0x in ?? () ---Type return to continue, or q return to quit--- #68 0x in ?? () #69 0x in ?? () #70 0x47012f00 in ?? () #71 0x in ?? () #72 0x4b7f in ?? () #73 0x in ?? () #74 0x44d3 in ?? () #75 0x in ?? () #76
Job
- This mail is in HTML. Some elements may be ommited in plain text. - Wal -Mart is looking for M y s t er y S h o p p e r s to help us carry out evalutions in your area. Please visit our page to SignUp .. ___ 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: pkg audit -F segfault on sparc64 and ia64 [WAS: Re: pkg audit segfault]
On Sat, Apr 21, 2012 at 11:34:24PM +0200, Baptiste Daroussin wrote: Fixed in git thank you for reporting On Wed, Apr 18, 2012 at 08:05:54PM +0200, Pietro Cerutti wrote: On 2012-Apr-18, 13:44, Anton Shterenlikht wrote: On Mon, Apr 16, 2012 at 04:13:06PM +0100, Anton Shterenlikht wrote: On Mon, Apr 16, 2012 at 04:58:27PM +0200, Julien Laffaye wrote: On 04/16/2012 04:21 PM, Anton Shterenlikht wrote: pkg audit -F On my 9.0-RELEASE amd64, it works fine. segfault also on sparc64 r230787M I have a couple of sparc64 machines on which I can test, but that won't be before next week.. I'll follow-up. # pkg -vvv version: 1.0-beta11 abi: freebsd:10:sparc64:64 db dir: /var/db/pkg cache dir: /var/cache/pkg ports dir: /usr/ports Log into syslog: yes Assume always yes: no Handle rc scripts: no Track shlibs: no Automatic depdency tracking: no Custom keywords directory: none Repository: none # # pkg audit -F http://portaudit.FreeBSD.org/auditfile.tbz 100% 76KB 75.7KB/s 75.7KB/s 00:00 0 problem(s) in your installed packages found. Segmentation fault (core dumped) # gdb /usr/local/sbin/pkg pkg.core 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 sparc64-marcel-freebsd... Core was generated by `pkg'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libpkg.so.0...done. Loaded symbols for /usr/local/lib/libpkg.so.0 Reading symbols from /lib/libutil.so.9...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libjail.so.1...done. Loaded symbols for /lib/libjail.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libarchive.so.5...done. Loaded symbols for /usr/lib/libarchive.so.5 Reading symbols from /lib/libsbuf.so.6...done. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /usr/lib/libfetch.so.6...done. Loaded symbols for /usr/lib/libfetch.so.6 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libedit.so.7...done. Loaded symbols for /lib/libedit.so.7 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/libbz2.so.4...done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/lib/liblzma.so.5...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /lib/libbsdxml.so.4...done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /usr/lib/libssl.so.6...done. Loaded symbols for /usr/lib/libssl.so.6 Reading symbols from /lib/libmd.so.5...done. Loaded symbols for /lib/libmd.so.5 Reading symbols from /lib/libncurses.so.8...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x407f31a8 in __sparc_utrap_install () from /lib/libc.so.7 [New Thread 41c04400 (LWP 100130/pkg)] (gdb) bt #0 0x407f31a8 in __sparc_utrap_install () from /lib/libc.so.7 #1 0x407f32cc in __sparc_utrap_install () from /lib/libc.so.7 #2 0x407f3570 in __sparc_utrap_install () from /lib/libc.so.7 #3 0x407f2dac in __sparc_utrap_install () from /lib/libc.so.7 #4 0x40225b74 in dlsym () from /libexec/ld-elf.so.1 #5 0x40225b74 in dlsym () from /libexec/ld-elf.so.1 Previous frame identical to this frame (corrupt stack?) (gdb) -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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 -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp I confirm that in v 1.0-beta12 pkg audit works fine on both sparc64 and ia64. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___
FreeBSD Port: ntp-4.2.6p5
I have a FreeBSD 9.0-RELEASE system built form sources that ntpd compile from the port with default options immediately crashes when launched. However when running it with the -d option on the command line to try and determine the cause the program runs fine and doesn't crash. I have another very similar system built with the same /etc/make.conf and /etc/src.conf files only with more ports installed than this system which doesn't have the problem. So I rebuilt this system entirely again, doing the full make buildworld, make buildkernel and installation. Followed by a portmaster -af to reinstall all ports problem persisted. I also deleted the ntp.conf and copied the one form the FreeBSD /usr/src/etc/ntp.conf file to rule out configuration file corruption as the cause. I also tried the net/ntp-devel branch port, similar problem as well, only it exists with a signal 10 when not in debugging mode whereas the net/ntp branch port gives me a signal 11. Further searching and I finally discovered the version of pearl on the working system was from the 5.14 branch and not the 5.12 branch. Updating pearl and recompiling all pearl dependent ports seems to have resolved the issue. Below is information about the system, and relevant log files, everything is working for me now, but I wanted to pass this information on in case there is something useful in it to help you maintain the port. Proxy1# uname -a FreeBSD proxy1.orscheln.com 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Apr 24 09:23:20 CDT 2012 intpr...@proxy1.orscheln.com:/usr/obj/usr/src/sys/GENERIC amd64 Log files from a startup of: /etc/rc.d/ntpd start Apr 25 09:06:48 proxy1 ntpd[59906]: ntpd 4.2.6p5@1.2349 Wed Apr 25 14:06:07 UTC 2012 (1) Apr 25 09:06:48 proxy1 kernel: pid 59907 (ntpd), uid 0: exited on signal 11 (core dumped) proxy1# ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -d ntpd 4.2.6p5@1.2349 Wed Apr 25 14:06:07 UTC 2012 (1) 25 Apr 09:07:36 ntpd[59923]: proto: precision = 0.698 usec event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled Finished Parsing!! 25 Apr 09:07:36 ntpd[59923]: ntp_io: estimated max descriptors: 11095, initial socket boundary: 20 25 Apr 09:07:36 ntpd[59923]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 25 Apr 09:07:36 ntpd[59923]: Listen and drop on 1 v6wildcard :: UDP 123 25 Apr 09:07:36 ntpd[59923]: Listen normally on 2 bce0 fe80::7a2b:cbff:fe68:9f1e UDP 123 restrict: op 1 addr fe80::7a2b:cbff:fe68:9f1e mask ::::::: mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 3 bce1 fe80::7a2b:cbff:fe68:9f1f UDP 123 restrict: op 1 addr fe80::7a2b:cbff:fe68:9f1f mask ::::::: mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 4 lo0 ::1 UDP 123 restrict: op 1 addr ::1 mask ::::::: mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 5 lo0 fe80::1 UDP 123 restrict: op 1 addr fe80::1 mask ::::::: mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 6 lo0 127.0.0.1 UDP 123 restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 7 DMZ 10.50.20.5 UDP 123 restrict: op 1 addr 10.50.20.5 mask 255.255.255.255 mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 8 DMZ 10.52.20.5 UDP 123 restrict: op 1 addr 10.52.20.5 mask 255.255.255.255 mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: peers refreshed 25 Apr 09:07:36 ntpd[59923]: Listening on routing socket on fd #29 for interface updates peer_clear: at 0 next 1 associd 24691 refid INIT event at 0 50.22.155.163 8011 81 mobilize assoc 24691 newpeer: 10.50.20.5-50.22.155.163 mode 3 vers 4 poll 6 9 flags 0x101 0x1 ttl 0 key peer_clear: at 0 next 2 associd 24692 refid INIT event at 0 173.230.144.109 8011 81 mobilize assoc 24692 newpeer: 10.50.20.5-173.230.144.109 mode 3 vers 4 poll 6 9 flags 0x101 0x1 ttl 0 key peer_clear: at 0 next 3 associd 24693 refid INIT event at 0 24.124.0.251 8011 81 mobilize assoc 24693 newpeer: 10.50.20.5-24.124.0.251 mode 3 vers 4 poll 6 9 flags 0x101 0x1 ttl 0 key event at 0 0.0.0.0 c016 06 restart event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM event at 0 0.0.0.0 c011 01 freq_not_set receive: at 0 10.50.20.5-10.26.146.37 mode 1 len 48 transmit: at 0 10.50.20.5-10.26.146.37 mode 2 len 48 receive: at 0 10.50.20.5-10.26.10.3 mode 3 len 48 transmit: at 0 10.50.20.5-10.26.10.3 mode 4 len 48 receive: at 0 10.50.20.5-10.21.130.2 mode 1 len 48 transmit: at 0 10.50.20.5-10.21.130.2 mode 2 len 48 receive: at 0 10.50.20.5-10.22.160.103 mode 3 len 48 transmit: at 0 10.50.20.5-10.22.160.103 mode 4 len 48 receive: at 0 10.50.20.5-10.26.112.9 mode 3 len 48 transmit: at 0 10.50.20.5-10.26.112.9 mode 4 len 48 /etc/make.conf # Use OpenSSL from ports instead of base
RE: FreeBSD Port: ntp-4.2.6p5
-Original Message- From: Dean Weimer Sent: Wednesday, April 25, 2012 9:54 AM To: 'c...@freebsd.org' Cc: 'po...@freebsd.org' Subject: FreeBSD Port: ntp-4.2.6p5 I have a FreeBSD 9.0-RELEASE system built form sources that ntpd compile from the port with default options immediately crashes when launched. However when running it with the -d option on the command line to try and determine the cause the program runs fine and doesn't crash. I have another very similar system built with the same /etc/make.conf and /etc/src.conf files only with more ports installed than this system which doesn't have the problem. So I rebuilt this system entirely again, doing the full make buildworld, make buildkernel and installation. Followed by a portmaster -af to reinstall all ports problem persisted. I also deleted the ntp.conf and copied the one form the FreeBSD /usr/src/etc/ntp.conf file to rule out configuration file corruption as the cause. I also tried the net/ntp-devel branch port, similar problem as well, only it exists with a signal 10 when not in debugging mode whereas the net/ntp branch port gives me a signal 11. Further searching and I finally discovered the version of pearl on the working system was from the 5.14 branch and not the 5.12 branch. Updating pearl and recompiling all pearl dependent ports seems to have resolved the issue. Below is information about the system, and relevant log files, everything is working for me now, but I wanted to pass this information on in case there is something useful in it to help you maintain the port. [...snip...] Correction, I tried a restart shortly after sending this, it now no longer starts without the -d option on the command line again. Any suggestions for additional troubleshooting? Thanks, Dean Weimer Network Administrator Orscheln Management Co ___ 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: Computer issues
Hi, as some of you might have noticed, I've been absent lately. On a reboot my CPU fan decided to stop working. I should have a replacement computer in one or two weeks. Until then, my access is rather limited and without access to BSD. Glad to hear it's nothing serious, hope you get back up and running soon. BTW, I've been looking at your patch for testing and it's really great. I've made a few small tweaks which I can share when you're back online. I thank you a LOT for saving me from the work and doing such a nice job at it too! Thanks, Steve ___ 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
ports/166399: Re: Foswiki port
Kevin Oberman wrote on 25.04.2012 02:50: On Tue, Apr 24, 2012 at 12:06 PM, Doug Sampsondo...@dawnsign.com wrote: Hello- When will Foswiki be updated to 1.1.4? It's currently at 1.1.3 and doesn't work with Perl 5.14 but 1.1.4 does. Version 1.1.5 is coming out soon and I'd like to upgrade to 1.1.4 and make sure all works smoothly before version 1.1.5 gets released. I submitted the update to 1.1.5 to ports a while ago. Just waiting for a commit. See PR ports/166399 Hi Kevin, Doug. Sorry, I forgot to say that this patch is incomplete. Updated port fails to uninstall. Can you please investigate? Here is the log: http://people.freebsd.org/~rm/foswiki-1.1.5.log -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: FreeBSD Port: ntp-4.2.6p5
In message cacc65656ed5c44fba651f3d2b99b808354a3...@neuman.orscheln.oi.loca l, Dean Weimer writes: I have a FreeBSD 9.0-RELEASE system built form sources that ntpd compile from the port with default options immediately crashes when launched. However wh en running it with the -d option on the command line to try and determine the cause the program runs fine and doesn't crash. I have another very similar system built with the same /etc/make.conf and /e tc/src.conf files only with more ports installed than this system which doesn 't have the problem. So I rebuilt this system entirely again, doing the full make buildworld, make buildkernel and installation. Followed by a portmaste r -af to reinstall all ports problem persisted. I also deleted the ntp.conf and copied the one form the FreeBSD /usr/src/etc/ntp.conf file to rule out co nfiguration file corruption as the cause. I also tried the net/ntp-devel bra nch port, similar problem as well, only it exists with a signal 10 when not i n debugging mode whereas the net/ntp branch port gives me a signal 11. Bus errors (access violations in text, e.g. JMP) and segmentation violations (access violations in the data or stack) may be due to bad memory. You can test this out by copying ntpd from a working system to the other. Use pkg_create to create a binary package on the working system and pkg_add on the other. You may want to check out configuration on the non-working system. In regard to debugging mode, the code will use a different execution path and your memory map will be slightly different, bypassing tickling whatever causes ntpd to crash. Further searching and I finally discovered the version of pearl on the workin g system was from the 5.14 branch and not the 5.12 branch. Updating pearl an d recompiling all pearl dependent ports seems to have resolved the issue. Be low is information about the system, and relevant log files, everything is wo rking for me now, but I wanted to pass this information on in case there is s omething useful in it to help you maintain the port. Personally, I haven't had problems with Perl 5.12 either. My infrastructure is at 5.14 currently but when it was at 5.12 I had no issues either. Proxy1# uname -a FreeBSD proxy1.orscheln.com 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Apr 24 09 :23:20 CDT 2012 intpr...@proxy1.orscheln.com:/usr/obj/usr/src/sys/GENERIC amd64 Log files from a startup of: /etc/rc.d/ntpd start Apr 25 09:06:48 proxy1 ntpd[59906]: ntpd 4.2.6p5@1.2349 Wed Apr 25 14:06:07 U TC 2012 (1) Apr 25 09:06:48 proxy1 kernel: pid 59907 (ntpd), uid 0: exited on signal 11 ( core dumped) proxy1# ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -d ntpd 4.2.6p5@1.2349 Wed Apr 25 14:06:07 UTC 2012 (1) 25 Apr 09:07:36 ntpd[59923]: proto: precision = 0.698 usec event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled Finished Parsing!! 25 Apr 09:07:36 ntpd[59923]: ntp_io: estimated max descriptors: 11095, initia l socket boundary: 20 25 Apr 09:07:36 ntpd[59923]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 25 Apr 09:07:36 ntpd[59923]: Listen and drop on 1 v6wildcard :: UDP 123 25 Apr 09:07:36 ntpd[59923]: Listen normally on 2 bce0 fe80::7a2b:cbff:fe68:9 f1e UDP 123 restrict: op 1 addr fe80::7a2b:cbff:fe68:9f1e mask :::::f fff:: mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 3 bce1 fe80::7a2b:cbff:fe68:9 f1f UDP 123 restrict: op 1 addr fe80::7a2b:cbff:fe68:9f1f mask :::::f fff:: mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 4 lo0 ::1 UDP 123 restrict: op 1 addr ::1 mask ::::::: mflags 0 0003000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 5 lo0 fe80::1 UDP 123 restrict: op 1 addr fe80::1 mask ::::::: mfla gs 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 6 lo0 127.0.0.1 UDP 123 restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 3000 flags 0001 25 Apr 09:07:36 ntpd[59923]: Listen normally on 7 DMZ 10.50.20.5 UDP 123 restrict: op 1 addr 10.50.20.5 mask 255.255.255.255 mflags 3000 flags 000 1 25 Apr 09:07:36 ntpd[59923]: Listen normally on 8 DMZ 10.52.20.5 UDP 123 restrict: op 1 addr 10.52.20.5 mask 255.255.255.255 mflags 3000 flags 000 1 25 Apr 09:07:36 ntpd[59923]: peers refreshed 25 Apr 09:07:36 ntpd[59923]: Listening on routing socket on fd #29 for interf ace updates peer_clear: at 0 next 1 associd 24691 refid INIT event at 0 50.22.155.163 8011 81 mobilize assoc 24691 newpeer: 10.50.20.5-50.22.155.163 mode 3 vers 4 poll 6 9 flags 0x101 0x1 ttl 0 key peer_clear: at 0 next 2 associd 24692 refid INIT event at 0 173.230.144.109 8011 81 mobilize assoc 24692 newpeer: 10.50.20.5-173.230.144.109 mode 3 vers 4 poll 6 9 flags 0x101 0x1 t tl 0 key peer_clear: at 0
Need a little help with a dynamic linking problem
My question relates to a port that I am doing of gthumb v2.14.3 to FreeBSD. Because gthumb is fundamentally a gnome application, I am cross-posting my question to both the ports and gnome mailing lists. (My apologies if that means that some of you see this twice.) After a modest but unexpected amount of gnashing of teeth and tearing of hair, I have been able to get gthumb 2.14.3 built and installed on my FreeBSD 8.2 system. Now comes to the fun part... I have installed the whole thing under a special (temporary) directory that I created called /usr/local/hacked. When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Quite obviously, I have been away from working on the GNU software development toolchain (and its friends, like ld-elf.so) for far far too long, because I no longer even know how this stuff is even supposed to work, i.e. when it is (knock on wood) working correctly. So if someone who knows this stuff can take pity on me and pass me a clue about what I need to do to resolve the above dynamic linking failure, I sure would appreciate it. Some relevant background: The main gthumb binary is installed in /usr/local/hacked/bin/gthumb and that's what I am running when I run it. It seems pretty obviously to me that the main gthumb executable, when executed, is then trying to dynamically pull in various of the *.so shared library files that got installed into /usr/local/hacked/lib/gthumb/extensions directory as part of the nominal build+install process for gthumb. One last important point: I've checked, and the symbol gth_viewer_page_get_type _is_ in fact defined. It is defined within the main gthumb executable itself: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type So, um, sombody please pass me a clue... How come the dynamic linker doesn't seem to know that the symbol it is looking for was and is defined in the main executable file that the present process originated with? (This specific lack of cognition on the part of the dynamic linker seems to me to be rather reminicent of Alzheimer's.) Regards, rfg P.S. I have already tried both of the following commands prior to executing my gthumb executable and neither of these made a bit of difference to the outcome. I still got the exact same dynamic linker (fatal) error in both cases... setenv LD_LIBRARY_PATH /usr/local/hacked/bin setenv LD_LIBRARY_PATH /usr/local/hacked/lib/gthumb/extensions ___ 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: Need a little help with a dynamic linking problem
In message 450d1c59-c403-463b-9c35-6af26f63d...@mac.com, you wrote: On Apr 25, 2012, at 5:01 PM, Ronald F. Guilmette wrote: When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer .so: Undefined symbol gth_viewer_page_get_type Does running ldconfig /usr/local/hacked/lib help? Not here it doesn't... root# ldconfig /usr/local/hacked/lib ldconfig: /usr/local/hacked/lib: ignoring directory not owned by root But anyway, why would it? The ``missing'' symbol is defined in the file /usr/local/hacked/bin/gthumb, as I said. ^^^ What does ldd say about things? Which things? % ldd /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: libm.so.5 = /lib/libm.so.5 (0x800c0) libc.so.7 = /lib/libc.so.7 (0x800647000) % ldd /usr/local/hacked/bin/gthumb /usr/local/hacked/bin/gthumb: libclutter-gtk-0.10.so.0 = /usr/local/lib/libclutter-gtk-0.10.so.0 (0x800718000) libclutter-glx-1.0.so.0 = /usr/local/lib/libclutter-glx-1.0.so.0 (0x800823000) libSM.so.6 = /usr/local/lib/libSM.so.6 (0x800a71000) libICE.so.6 = /usr/local/lib/libICE.so.6 (0x800b79000) libgtk-x11-2.0.so.0 = /usr/local/lib/libgtk-x11-2.0.so.0 (0x800c93000) libgdk-x11-2.0.so.0 = /usr/local/lib/libgdk-x11-2.0.so.0 (0x8011ac000) libatk-1.0.so.0 = /usr/local/lib/libatk-1.0.so.0 (0x80135f000) libpangocairo-1.0.so.0 = /usr/local/lib/libpangocairo-1.0.so.0 (0x80148) libgdk_pixbuf-2.0.so.0 = /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0x80158d000) libcairo.so.2 = /usr/local/lib/libcairo.so.2 (0x8016ab000) libpng.so.6 = /usr/local/lib/libpng.so.6 (0x801863000) libpango-1.0.so.0 = /usr/local/lib/libpango-1.0.so.0 (0x80198d000) libgconf-2.so.4 = /usr/local/lib/libgconf-2.so.4 (0x801ad6000) libgio-2.0.so.0 = /usr/local/lib/libgio-2.0.so.0 (0x801c12000) libz.so.5 = /lib/libz.so.5 (0x801e36000) libgmodule-2.0.so.0 = /usr/local/lib/libgmodule-2.0.so.0 (0x801f4b000) libgobject-2.0.so.0 = /usr/local/lib/libgobject-2.0.so.0 (0x80204e000) libgthread-2.0.so.0 = /usr/local/lib/libgthread-2.0.so.0 (0x80219a000) libglib-2.0.so.0 = /usr/local/lib/libglib-2.0.so.0 (0x80229e000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x802488000) libm.so.5 = /lib/libm.so.5 (0x802591000) libthr.so.3 = /lib/libthr.so.3 (0x8026b1000) libc.so.7 = /lib/libc.so.7 (0x8027ca000) libGL.so.1 = /usr/local/lib/libGL.so.1 (0x802a0c000) libdrm.so.2 = /usr/local/lib/libdrm.so.2 (0x802b94000) libjson-glib-1.0.so.0 = /usr/local/lib/libjson-glib-1.0.so.0 (0x802c9e000) libXinerama.so.1 = /usr/local/lib/libXinerama.so.1 (0x802dbb000) libXi.so.6 = /usr/local/lib/libXi.so.6 (0x802ebd000) libXrandr.so.2 = /usr/local/lib/libXrandr.so.2 (0x802fcc000) libXext.so.6 = /usr/local/lib/libXext.so.6 (0x8030d4000) libXcursor.so.1 = /usr/local/lib/libXcursor.so.1 (0x8031e6000) libXcomposite.so.1 = /usr/local/lib/libXcomposite.so.1 (0x8032f) libXdamage.so.1 = /usr/local/lib/libXdamage.so.1 (0x8033f3000) libpangoft2-1.0.so.0 = /usr/local/lib/libpangoft2-1.0.so.0 (0x8034f5000) libXfixes.so.3 = /usr/local/lib/libXfixes.so.3 (0x803627000) libpixman-1.so.9 = /usr/local/lib/libpixman-1.so.9 (0x80372d000) libxcb-shm.so.0 = /usr/local/lib/libxcb-shm.so.0 (0x8038ac000) libxcb-render.so.0 = /usr/local/lib/libxcb-render.so.0 (0x8039ae000) libXrender.so.1 = /usr/local/lib/libXrender.so.1 (0x803ab6000) libX11.so.6 = /usr/local/lib/libX11.so.6 (0x803bbf000) libxcb.so.2 = /usr/local/lib/libxcb.so.2 (0x803df4000) libXau.so.6 = /usr/local/lib/libXau.so.6 (0x803f0e000) libXdmcp.so.6 = /usr/local/lib/libXdmcp.so.6 (0x804011000) libpthread-stubs.so.0 = /usr/local/lib/libpthread-stubs.so.0 (0x804116000) librpcsvc.so.5 = /usr/lib/librpcsvc.so.5 (0x804217000) libfontconfig.so.1 = /usr/local/lib/libfontconfig.so.1 (0x80432) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x804453000) libexpat.so.6 = /usr/local/lib/libexpat.so.6 (0x8045db000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x8046ff000) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libpcre.so.0 = not found (0x0) libbz2.so.4 = /usr/lib/libbz2.so.4 (0x8048fa000) libpcre.so.0 = not found (0x0) libORBit-2.so.0 = /usr/local/lib/libORBit-2.so.0 (0x804a0a000) libpcre.so.0 = not found (0x0) libpcre.so.1 =
Re: Need a little help with a dynamic linking problem
Without being able to look at the details in-depth myself, it looks like the shared object is looking for a symbol which the RTLD can't resolve. The symbol is defined in the gthumb application itself. Is that symbol exported such that shared objects can reference it? If the problem is still unresolved by tomorrow, I can draft up a sample and confirm my suspicions (that non-exported symbols won't be resolvable by dynamically-loaded shared objects). Thanks, Shawn Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 25, 2012 6:02 PM, Ronald F. Guilmette r...@tristatelogic.com wrote: My question relates to a port that I am doing of gthumb v2.14.3 to FreeBSD. Because gthumb is fundamentally a gnome application, I am cross-posting my question to both the ports and gnome mailing lists. (My apologies if that means that some of you see this twice.) After a modest but unexpected amount of gnashing of teeth and tearing of hair, I have been able to get gthumb 2.14.3 built and installed on my FreeBSD 8.2 system. Now comes to the fun part... I have installed the whole thing under a special (temporary) directory that I created called /usr/local/hacked. When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Quite obviously, I have been away from working on the GNU software development toolchain (and its friends, like ld-elf.so) for far far too long, because I no longer even know how this stuff is even supposed to work, i.e. when it is (knock on wood) working correctly. So if someone who knows this stuff can take pity on me and pass me a clue about what I need to do to resolve the above dynamic linking failure, I sure would appreciate it. Some relevant background: The main gthumb binary is installed in /usr/local/hacked/bin/gthumb and that's what I am running when I run it. It seems pretty obviously to me that the main gthumb executable, when executed, is then trying to dynamically pull in various of the *.so shared library files that got installed into /usr/local/hacked/lib/gthumb/extensions directory as part of the nominal build+install process for gthumb. One last important point: I've checked, and the symbol gth_viewer_page_get_type _is_ in fact defined. It is defined within the main gthumb executable itself: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type So, um, sombody please pass me a clue... How come the dynamic linker doesn't seem to know that the symbol it is looking for was and is defined in the main executable file that the present process originated with? (This specific lack of cognition on the part of the dynamic linker seems to me to be rather reminicent of Alzheimer's.) Regards, rfg P.S. I have already tried both of the following commands prior to executing my gthumb executable and neither of these made a bit of difference to the outcome. I still got the exact same dynamic linker (fatal) error in both cases... setenv LD_LIBRARY_PATH /usr/local/hacked/bin setenv LD_LIBRARY_PATH /usr/local/hacked/lib/gthumb/extensions ___ 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: Need a little help with a dynamic linking problem
In message CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3l_so732epv1v...@mail.gmail.com , you wrote: Without being able to look at the details in-depth myself, it looks like the shared object is looking for a symbol which the RTLD can't resolve. That much seems self-evident. The error message itself in effect says precisely that. The symbol is defined in the gthumb application itself. Is that symbol exported such that shared objects can reference it? Based on the outcome, I would have to say that this answer to that question is also (self-evidently?) no. But I'm really not sure, frankly, because I have never before seen an instance of anybody trying to do something screwy like this... I mean having a shared library that depends upon somthing (a symbol) that is intended to be satisfied by the main executable. Frankly, this seems altogether screwy and bizzare to me. Unsually, the main executable depends on (or uses, dynamically) a number of shared libraries. Sharded libraries in turn typically depend on either (a) nothing at all or else (b) some combination of other shared and/or static linking libraries. That has always been my own past experience anyway. By like I said, I have been away from the software development tools for awhile, so mabe having a dynamic library that depends upon something in the main executable is considered kosher now. (Or maybe it ain't, actually, but it is nonthelwess one of those screwy things that the current or original developer or maintainer found out that he could get away with anyway, you know, like JUST over on that well-known hobbist OS whose name begins with the letter L.) Like I say. I don't know, cuz I'm not the developer/maintainer of this thing. If the problem is still unresolved by tomorrow... It doesn't seem to be healing on its own so far... I can draft up a sample and confirm my suspicions (that non-exported symbols won't be resolvable by dynamically-loaded shared objects). Oh, I do believe that you are 100% correct about that. This much, at least, I _do_ remember from ancient times when I worked on the GNU software develop- ment tools (including the linker). In every object file... either a main executable or a shared library, there are symbols that are externally available/visible and then there are ones that aren't... i.e. that are local, and that the dynamic linker either never sees or, at any rate, doesn't pay any attention to. But my dim recollection is that you can easily tell which is which by looking at the type letter that appears next to the symbol in the `nm' output. For example: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type ^ Here, the symbol type indicator is the letter `T', meaning that this is a ``text'' (executable/code) type of symbol. That much I know for sure. The part I am less clear about anymore is that I _think_ I remember that when the type letter on the nm output is a capital letter (as in this case) it means that the symbol in question is ``public'' and available for linking. (Actually, I _am_ pretty darn sure that this is indeed what CAPITAL type letters in the nm output mean.) The only other thing that I can't quite remember anymore is whether such a symbol is always and necessarily available for *dynamic* linking purposes. It might perhaps just be externally available visible ONLY for *static* linking purposes, in which case that might explain why I am seeing a `T' on the nm output for the required symbol, but yet the dynamic linker clearly can't seem to find it. Regards, rfg ___ 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: Need a little help with a dynamic linking problem
On Apr 25, 2012, at 5:01 PM, Ronald F. Guilmette wrote: When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Does running ldconfig /usr/local/hacked/lib help? What does ldd say about things? Regards, -- -Chuck ___ 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: arduino-1.0_2,1 execution failure
On Tue, 24 Apr 2012, enoch wrote: $ arduino Exception in thread main java.lang.NoClassDefFoundError: gnu/io/CommPortIdentifier at processing.app.Editor.populateSerialMenu(Editor.java:969) at processing.app.Editor.buildToolsMenu(Editor.java:697) at processing.app.Editor.buildMenuBar(Editor.java:482) at processing.app.Editor.init(Editor.java:204) at processing.app.Base.handleOpen(Base.java:700) at processing.app.Base.handleOpen(Base.java:665) at processing.app.Base.handleNew(Base.java:561) at processing.app.Base.init(Base.java:301) at processing.app.Base.main(Base.java:190) Caused by: java.lang.ClassNotFoundException: gnu.io.CommPortIdentifier at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) ... 9 more $ uname -prs FreeBSD 8.3-STABLE amd64 How was it installed? I just tried a fresh 8.3 i386 VM, installing from packages, and the Arduino IDE comes right up. ___ 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: Request for graphics/rawtherapee and graphics/darktable update
Hi Gosha! Гуляев Гоша wrote on 21.04.2012 11:24: Good day everyone! There is new versions of therse applications available. Maybe someone can update it in ports? Thank you! rawtherapee was just updated, and darktable has an active maintainer (cc'ed). It always better to let maintainer know first, or at least add him to cc: when writing to ports@. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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
