Re: net/avahi-app core dumps signal 11
Hi, On Fri, 31 Jan 2014 04:40:32 -0200 Sergio de Almeida Lenzi lenzi.ser...@gmail.com wrote: Em Qua, 2014-01-29 às 11:54 +0100, Thomas Mueller escreveu: On Tue, 21 Jan 2014 23:37:08 -0200, Sergio de Almeida Lenzi wrote: avahi-daemon dumps core, and I am unable to determinw why because it aborts core just before reaching the main() procedure.. = #0 0x000801304604 in pthread_testcancel () from /lib/libthr.so.3 #1 0x0008012fc706 in open () from /lib/libthr.so.3 #2 0x000801517227 in __gets_chk () from /lib/libssp.so.0 #3 0x0008015173d2 in __chk_fail () from /lib/libssp.so.0 #4 0x000801516ace in .init () from /lib/libssp.so.0 #5 0x7fffd130 in ?? () #6 0x00080061e6d1 in r_debug_state () from /libexec/ld-elf.so.1 #7 0x00080061dd57 in __tls_get_addr () from /libexec/ld-elf.so.1 #8 0x00080061c099 in .text () from /libexec/ld-elf.so.1 #9 0x in ?? () = any ideas??? Seems like a bad interaction with stack protector (libssp). I managed to get working binaries (10.0-STABLE, amd64) by adding --disable-stack-protector to CONFIGURE_ARGS I just did this and can confirm that this helps. Erich ___ 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 you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ databases/sqlrelay | 0.53.1 | 0.54 +-+ games/doomsday | 1.12.2 | 1.14.0-build1126 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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: Sage update
On Friday 31 January 2014 00:07:31 Montgomery-Smith, Stephen wrote: On 01/30/2014 05:32 PM, Ajtim wrote: I am not lucky: Now installing the Maxima library as '/usr/ports/math/sage/work/sage-6.0/local/lib/ecl//maxima.fas'... New ASDF encountered real6m29.758s user5m28.766s sys 0m28.508s Successfully installed maxima-5.29.1.p4 Deleting temporary build directory /usr/ports/math/sage/work/sage-6.0/local/var/tmp/sage/build/maxima-5.29.1.p4 Finished installing maxima-5.29.1.p4.spkg make[4]: Leaving directory `/usr/ports/math/sage/work/sage-6.0/build' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/ports/math/sage/work/sage-6.0/build' real18m28.872s user94m55.810s sys 7m31.317s *** Error building Sage. The following package(s) may have failed to build: package: r-3.0.2.p0 log file: /usr/ports/math/sage/work/sage-6.0/logs/pkgs/r-3.0.2.p0.log build directory: /usr/ports/math/sage/work/sage-6.0/local/var/tmp/sage/build/r-3.0.2.p0 The build directory may contain configuration files and other potentially helpful information. WARNING: if you now run 'make' again, the build directory will, by default, be deleted. Set the environment variable SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. gmake[2]: *** [build] Error 1 gmake[2]: Leaving directory `/usr/ports/math/sage/work/sage-6.0' === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/math/sage *** Error code 1 Stop. make: stopped in /usr/ports/math/sage Can you send me this file: /usr/ports/math/sage/work/sage-6.0/logs/pkgs/r-3.0.2.p0.log Because the build is multithreaded, the install.log gets different builds mixed up, and the error that caused the problem isn't always in the last few lines. However, I am also getting a build error at r-3.0.2.p0, and it is exactly the same error as I was getting before. All I want to check is whether you are getting the same error as me. I am also getting a build error with scipy and matplotlib-1.2.1. The scipy error exactly matches an error message I received from one of you earlier today (before I applied the fix). This means that whatever the problem is, the fix didn't fix it. Here is te log. Thanks to the all for the hard work... -- Mitja --- http://www.redbubble.com/people/lumiwa ___ 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: Help with new port - required port already installed error
Fernando Apesteguía wrote: El 31/01/2014 01:01, Rod Person rodper...@rodperson.com escribió: Hi, I working on a new new port that requires the existing port graphics/py-qt4-svg. If this port is installed on the sytem already I get the error below. I have tried this on a secondary system of mine and also redports.org and get the same error. Is there anyway I can fix this. This is a like the port I'm working on http://www.rodperson.com/usr/www/users/pl905/rodperson.com/DL/spyder Not found. Wrong link? Sorry, correct link: http://www.rodperson.com/DL/spyder/ === Installing for py27-qt4-svg-4.10.3,1 === Checking if graphics/py-qt4-svg already installed === py27-qt4-svg-4.10.3,1 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of graphics/py-qt4-svg without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. -- Rod The lips of wisdom are closed, except to the ears of understanding - The Kybalion ___ 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: net/avahi-app core dumps signal 11
On 29 Jan 2014, at 11:54, Thomas Mueller tmuel...@sysgo.com wrote: On Tue, 21 Jan 2014 23:37:08 -0200, Sergio de Almeida Lenzi wrote: avahi-daemon dumps core, and I am unable to determinw why because it aborts core just before reaching the main() procedure.. = #0 0x000801304604 in pthread_testcancel () from /lib/libthr.so.3 #1 0x0008012fc706 in open () from /lib/libthr.so.3 #2 0x000801517227 in __gets_chk () from /lib/libssp.so.0 #3 0x0008015173d2 in __chk_fail () from /lib/libssp.so.0 #4 0x000801516ace in .init () from /lib/libssp.so.0 #5 0x7fffd130 in ?? () #6 0x00080061e6d1 in r_debug_state () from /libexec/ld-elf.so.1 #7 0x00080061dd57 in __tls_get_addr () from /libexec/ld-elf.so.1 #8 0x00080061c099 in .text () from /libexec/ld-elf.so.1 #9 0x in ?? () = any ideas??? Seems like a bad interaction with stack protector (libssp). I managed to get working binaries (10.0-STABLE, amd64) by adding --disable-stack-protector to CONFIGURE_ARGS Don't you think the stack protector code is trying to tell you the stack got smashed? :-) E.g. this is most likely a real buffer overflow or something, and it should be properly fixed, instead of removing the seat belts. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems with linking on FreeBSD-10
On Fri, Jan 31, 2014 at 12:19:46AM +, Montgomery-Smith, Stephen wrote: I maintain the port math/sage. The port builds its own version of the libreadline library. The port also uses lang/gcc instead of clang, because the port needs Fortran. The port is wanting to create a shared library called libR.so, which it wants to link with the libreadline library it created itself. So it issues this kind of command: gcc46 -Wl,-rpath=path-of-newly-made-library -o libR.so -lreadline I have left out most of the command for brevity. Not for brevity, but to make the diagnostic impossible. Unfortunately the libR.so pulls in /lib/libreadline - the version that comes with the base FreeBSD. I thought that -rpath flag was supposed to tell the linker where to find the library. But it doesn't. Show exact commands and exact error message. It is not possible to understand from you message is the failure at the static linking (ld(1)) or dynamic (at the program startup) stage. Just in case this might be useful: - -rpath only affects runtime search path - ld(1) search for libraries is directed with the -L path option. The failure is when using FreeBSD-10. With FreeBSD-8 it works great. I also assume that gcc46 uses /usr/local/bin/ld instead of /usr/bin/ld, since devel/binutils is a dependency of lang/gcc. Can anyone help me? Is this a bug with FreeBSD? Or is there some extra flag I can set with the linker to make it work? I have tried -rpath-link and -z origin, but these were random guesses. and I don't really know what I am doing. Thanks, Stephen ___ 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 pgpBG4HKMt2lM.pgp Description: PGP signature
Re: net/avahi-app core dumps signal 11
On Fri, 31 Jan 2014 14:15:13 +0100, Dimitry Andric wrote: On 29 Jan 2014, at 11:54, Thomas Mueller tmuel...@sysgo.com wrote: On Tue, 21 Jan 2014 23:37:08 -0200, Sergio de Almeida Lenzi wrote: avahi-daemon dumps core, and I am unable to determinw why because it aborts core just before reaching the main() procedure.. = #0 0x000801304604 in pthread_testcancel () from /lib/libthr.so.3 #1 0x0008012fc706 in open () from /lib/libthr.so.3 #2 0x000801517227 in __gets_chk () from /lib/libssp.so.0 #3 0x0008015173d2 in __chk_fail () from /lib/libssp.so.0 #4 0x000801516ace in .init () from /lib/libssp.so.0 #5 0x7fffd130 in ?? () #6 0x00080061e6d1 in r_debug_state () from /libexec/ld-elf.so.1 #7 0x00080061dd57 in __tls_get_addr () from /libexec/ld-elf.so.1 #8 0x00080061c099 in .text () from /libexec/ld-elf.so.1 #9 0x in ?? () = any ideas??? Seems like a bad interaction with stack protector (libssp). I managed to get working binaries (10.0-STABLE, amd64) by adding --disable-stack-protector to CONFIGURE_ARGS Don't you think the stack protector code is trying to tell you the stack got smashed? :-) That may well be. Then there is still the quesiotn why executables built on 9 appear to work while those built on 10 do no work. E.g. this is most likely a real buffer overflow or something, and it should be properly fixed, instead of removing the seat belts. Sure. -- Thomas Mueller ___ 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: Problems with linking on FreeBSD-10
The failure is when using FreeBSD-10. With FreeBSD-8 it works great. I Building ports on 10.0-RELEASE is lots more trouble than 9.2-RELEASE. 10.0-RELEASE built 874, 9.2-RELEASE built 953 still making, with http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/ports/jhs/*/Makefile.local cd /usr/ports/packages/All ; /bin/ls -1 | wc -l 10.0-RELEASE has 40 DUDS, 9.2-RELEASE has 7 DUDS so far in http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/jhs/etc/csh.cshrc.master Lot of broken ports in 10.0-RELEASE are cc errors, (Clang, 9.2 was gcc). Some are Stage failures. New tools breaking, typical of a .0 release. I was tempted to 10 by man urtwn (4) (WLAN), but then 10 src/ ripped out bind, 10.0 ports wasted time to delivered less. 9.2-RELEASE is better. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: net/avahi-app core dumps signal 11
[replying to my own message, oh my] On Fri, 31 Jan 2014 14:41:11 +0100, Thomas Mueller wrote: On Fri, 31 Jan 2014 14:15:13 +0100, Dimitry Andric wrote: On 29 Jan 2014, at 11:54, Thomas Mueller tmuel...@sysgo.com wrote: On Tue, 21 Jan 2014 23:37:08 -0200, Sergio de Almeida Lenzi wrote: avahi-daemon dumps core, and I am unable to determinw why because it aborts core just before reaching the main() procedure.. = #0 0x000801304604 in pthread_testcancel () from /lib/libthr.so.3 #1 0x0008012fc706 in open () from /lib/libthr.so.3 #2 0x000801517227 in __gets_chk () from /lib/libssp.so.0 #3 0x0008015173d2 in __chk_fail () from /lib/libssp.so.0 #4 0x000801516ace in .init () from /lib/libssp.so.0 #5 0x7fffd130 in ?? () #6 0x00080061e6d1 in r_debug_state () from /libexec/ld-elf.so.1 #7 0x00080061dd57 in __tls_get_addr () from /libexec/ld-elf.so.1 #8 0x00080061c099 in .text () from /libexec/ld-elf.so.1 #9 0x in ?? () = any ideas??? Seems like a bad interaction with stack protector (libssp). I managed to get working binaries (10.0-STABLE, amd64) by adding --disable-stack-protector to CONFIGURE_ARGS Don't you think the stack protector code is trying to tell you the stack got smashed? :-) That may well be. Then there is still the quesiotn why executables built on 9 appear to work while those built on 10 do no work. I had an older avahi build lying around on a 10-STABLE box (built December 19, 2013) and that does not show the problem. Now, when I build net/avahi-app from from current ports on that box, resulting binaries crash. [old build, December 19, 2013] nomad:/usr/ports/net/avahi-app# /usr/local/bin/avahi-browse Too few arguments [current build] nomad:/usr/ports/net/avahi-app# ./work/avahi-0.6.31/avahi-utils/.libs/avahi-browse Segmentation fault (core dumped) nomad:/usr/ports/net/avahi-app# size /usr/local/bin/avahi-browse work/avahi-0.6.31/avahi-utils/.libs/avahi-browse textdata bss dec hex filename 1958411764488 2524862a0 /usr/local/bin/avahi-browse 1958411764488 2524862a0 work/avahi-0.6.31/avahi-utils/.libs/avahi-browse Then there's a difference in the order of libraries in the ldd output, but I don't know if that is relevant: nomad:/usr/ports/net/avahi-app# ldd /usr/local/bin/avahi-browse work/avahi-0.6.31/avahi-utils/.libs/avahi-browse /usr/local/bin/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x80082) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x800a2f000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x800c82000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x800e8e000) libssp.so.0 = /lib/libssp.so.0 (0x801098000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x80129a000) libthr.so.3 = /lib/libthr.so.3 (0x8014a3000) libc.so.7 = /lib/libc.so.7 (0x8016c8000) work/avahi-0.6.31/avahi-utils/.libs/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x80082) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x800a2f000) libthr.so.3 = /lib/libthr.so.3 (0x800c82000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x800ea7000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x8010b3000) libssp.so.0 = /lib/libssp.so.0 (0x8012bd000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x8014bf000) libc.so.7 = /lib/libc.so.7 (0x8016c8000) On a hunch, I downgraded devel/dbus back from 1.6.18 to 1.6.12, now the resulting avahi programs no longer dump core. -- Thomas Mueller ___ 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: Help with new port - required port already installed error
On Fri, Jan 31, 2014 at 1:18 PM, Rod Person rodper...@rodperson.com wrote: Fernando Apesteguía wrote: El 31/01/2014 01:01, Rod Person rodper...@rodperson.com escribió: Hi, I working on a new new port that requires the existing port graphics/py-qt4-svg. If this port is installed on the sytem already I get the error below. I have tried this on a secondary system of mine and also redports.org and get the same error. Is there anyway I can fix this. This is a like the port I'm working on http://www.rodperson.com/usr/www/users/pl905/rodperson.com/DL/spyder Not found. Wrong link? Sorry, correct link: http://www.rodperson.com/DL/spyder/ What does make run-depends say? Does it say py-qt4-svg is installed? === Installing for py27-qt4-svg-4.10.3,1 === Checking if graphics/py-qt4-svg already installed === py27-qt4-svg-4.10.3,1 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of graphics/py-qt4-svg without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. -- Rod The lips of wisdom are closed, except to the ears of understanding - The Kybalion ___ 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: Help with new port - required port already installed error
Fernando Apesteguía wrote: On Fri, Jan 31, 2014 at 1:18 PM, Rod Person rodper...@rodperson.com wrote: Fernando Apesteguía wrote: El 31/01/2014 01:01, Rod Person rodper...@rodperson.com escribió: Hi, I working on a new new port that requires the existing port graphics/py-qt4-svg. If this port is installed on the sytem already I get the error below. I have tried this on a secondary system of mine and also redports.org and get the same error. Is there anyway I can fix this. This is a like the port I'm working on http://www.rodperson.com/usr/www/users/pl905/rodperson.com/DL/spyder Not found. Wrong link? Sorry, correct link: http://www.rodperson.com/DL/spyder/ What does make run-depends say? Does it say py-qt4-svg is installed? Yes. Same error. === Installing for py27-qt4-svg-4.10.3,1 === Checking if graphics/py-qt4-svg already installed === py27-qt4-svg-4.10.3,1 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of graphics/py-qt4-svg without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. -- Rod The lips of wisdom are closed, except to the ears of understanding - The Kybalion ___ 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 -- Rod The lips of wisdom are closed, except to the ears of understanding - The Kybalion ___ 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
net/avahi-app dumps core signal 11 on Freebsd 10 release or freebsd 10 stable SOLVED
Em Sex, 2014-01-31 às 17:14 +, k...@freebsd.org escreveu: Synopsis: net/avahi-app dumps core signal 11 on Freebsd 10 release or freebsd 10 stable State-Changed-From-To: open-closed State-Changed-By: kwm State-Changed-When: Fri Jan 31 17:14:17 UTC 2014 State-Changed-Why: Committed the disable stack protector, thanks for reporting. http://www.freebsd.org/cgi/query-pr.cgi?pr=186097 Thank you all for the fixed FreeBSD rocks ___ 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: Help with new port - required port already installed error
On Fri, Jan 31, 2014 at 11:06 AM, Rod Person rodper...@rodperson.comwrote:
Fernando Apesteguía wrote:
On Fri, Jan 31, 2014 at 1:18 PM, Rod Person rodper...@rodperson.com
wrote:
Fernando Apesteguía wrote:
El 31/01/2014 01:01, Rod Person rodper...@rodperson.com escribió:
Hi,
I working on a new new port that requires the existing port
graphics/py-qt4-svg. If this port is installed on the sytem already
I get the error below. I have tried this on a secondary system of
mine and also redports.org and get the same error. Is there anyway I
can fix this.
This is a like the port I'm working on
http://www.rodperson.com/usr/www/users/pl905/rodperson.com/DL/spyder
Not found. Wrong link?
Sorry, correct link:
http://www.rodperson.com/DL/spyder/
What does make run-depends say? Does it say py-qt4-svg is installed?
Yes. Same error.
You have an extra PyQt4/ at line
${PYTHON_SITELIBDIR}/PyQt4/PyQt4/QtSvg.so:${PORTSDIR}/graphics/py-qt4-svg \
=== Installing for py27-qt4-svg-4.10.3,1
=== Checking if graphics/py-qt4-svg already installed
=== py27-qt4-svg-4.10.3,1 is already installed
You may wish to ``make deinstall'' and install this port again
by ``make reinstall'' to upgrade it properly.
If you really wish to overwrite the old port of
graphics/py-qt4-svg without deleting it first, set the variable
FORCE_PKG_REGISTER in your environment or the make install
command line.
--
Rod
The lips of wisdom are closed, except to the ears of understanding
- The Kybalion
___
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
--
Rod
The lips of wisdom are closed, except to the ears of understanding
- The Kybalion
___
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
--
Cheers,
Henry
___
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
Samba to web
Hello. I'm in need of some suggestion about what software to use: I have a Samba server which I need to make visibile to users outside of its network. The users will be known (and the same who work from inside), so they will use the same credentials they directly use with Samba and should see, from the outside, the same folders they see from inside. The only strange requirement is that, from the outside, they should only be able to read, not write. VPNs are not a good choice: users are not teechies and they can't set them up themselves; OTOH I don't have access to the client computers, which could also change over time or be occasional stations. Furthermore I don't think I can achieve read-only behaviour this way. I was thinking more about some kind of web interface and I came up with some search results: _ smb2www was in the port tree, but removed a couple of years ago; maybe I could try to download and hack it; _ there's SMB Web Client (http://sourceforge.net/projects/smbwebclient/) _ Davenport (which brings WebDav in), _ Others? Before I start digging them all, has anyone faced this task before? Any hint? bye Thanks av. ___ 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: Help with new port - required port already installed error
On Fri, Jan 31, 2014 at 6:24 PM, Henry Hu henry.hu...@gmail.com wrote:
On Fri, Jan 31, 2014 at 11:06 AM, Rod Person rodper...@rodperson.comwrote:
Fernando Apesteguía wrote:
On Fri, Jan 31, 2014 at 1:18 PM, Rod Person rodper...@rodperson.com
wrote:
Fernando Apesteguía wrote:
El 31/01/2014 01:01, Rod Person rodper...@rodperson.com escribió:
Hi,
I working on a new new port that requires the existing port
graphics/py-qt4-svg. If this port is installed on the sytem already
I get the error below. I have tried this on a secondary system of
mine and also redports.org and get the same error. Is there anyway I
can fix this.
This is a like the port I'm working on
http://www.rodperson.com/usr/www/users/pl905/rodperson.com/DL/spyder
Not found. Wrong link?
Sorry, correct link:
http://www.rodperson.com/DL/spyder/
What does make run-depends say? Does it say py-qt4-svg is installed?
Yes. Same error.
You have an extra PyQt4/ at line
${PYTHON_SITELIBDIR}/PyQt4/PyQt4/QtSvg.so:${PORTSDIR}/graphics/py-qt4-svg \
Hence you should be seeing something like:
spyder-2.3.0beta2 depends on _some_path_here: not found.
ls-ing that path reveals the problem.
=== Installing for py27-qt4-svg-4.10.3,1
=== Checking if graphics/py-qt4-svg already installed
=== py27-qt4-svg-4.10.3,1 is already installed
You may wish to ``make deinstall'' and install this port again
by ``make reinstall'' to upgrade it properly.
If you really wish to overwrite the old port of
graphics/py-qt4-svg without deleting it first, set the variable
FORCE_PKG_REGISTER in your environment or the make install
command line.
--
Rod
The lips of wisdom are closed, except to the ears of understanding
- The Kybalion
___
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
--
Rod
The lips of wisdom are closed, except to the ears of understanding
- The Kybalion
___
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
--
Cheers,
Henry
___
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: Problems with linking on FreeBSD-10
On 01/31/14 07:25, Konstantin Belousov wrote: On Fri, Jan 31, 2014 at 12:19:46AM +, Montgomery-Smith, Stephen wrote: I maintain the port math/sage. The port builds its own version of the libreadline library. The port also uses lang/gcc instead of clang, because the port needs Fortran. The port is wanting to create a shared library called libR.so, which it wants to link with the libreadline library it created itself. So it issues this kind of command: gcc46 -Wl,-rpath=path-of-newly-made-library -o libR.so -lreadline I have left out most of the command for brevity. Not for brevity, but to make the diagnostic impossible. Here are more details. I have the -L there as well. It creates libR.so using a command like this: cc -std=gnu99 -shared -fopenmp -L/usr/home/stephen/sage/work/sage-6.0/local/lib/ -Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o libR.so CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cum.o dcf.o datetime.o debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o names.o objects.o options.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o version.o vfonts.o xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o` ../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a ../extra/tre/libtre.a -L/usr/home/stephen/sage/work/sage-6.0/local/lib -lf77blas -latlas -lgfortran -lm -lquadmath -lintl -lreadline -llzma -lrt -lm -liconv Now -Wl,-rpath is set, so it should find libreadline in /usr/home/stephen/sage/work/sage-6.0/local/lib. But instead it finds libreadline in /lib. So later when it does the following compilation to build R.bin: gcc -std=gnu99 -export-dynamic -fopenmp -L/usr/home/stephen/sage/work/sage-6.0/local/lib/ -Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o R.bin Rmain.o -L../../lib -lR ...it comes up with an error saying that rl_sort_completion_matches isn't found. And when I do an ldd or readelf -d on libR.so, I can see that it is trying to link to the wrong libreadline, and rl_sort_completion_matches is only defined in the other libreadline. Unfortunately the libR.so pulls in /lib/libreadline - the version that comes with the base FreeBSD. I thought that -rpath flag was supposed to tell the linker where to find the library. But it doesn't. Show exact commands and exact error message. It is not possible to understand from you message is the failure at the static linking (ld(1)) or dynamic (at the program startup) stage. Just in case this might be useful: - -rpath only affects runtime search path - ld(1) search for libraries is directed with the -L path option. The failure is when using FreeBSD-10. With FreeBSD-8 it works great. I also assume that gcc46 uses /usr/local/bin/ld instead of /usr/bin/ld, since devel/binutils is a dependency of lang/gcc. Can anyone help me? Is this a bug with FreeBSD? Or is there some extra flag I can set with the linker to make it work? I have tried -rpath-link and -z origin, but these were random guesses. and I don't really know what I am doing. Thanks, Stephen ___ 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: Help with new port - required port already installed error
Henry Hu wrote:
On Fri, Jan 31, 2014 at 11:06 AM, Rod Person rodper...@rodperson.com
mailto:rodper...@rodperson.com wrote:
Fernando Apesteguía wrote:
On Fri, Jan 31, 2014 at 1:18 PM, Rod Person
rodper...@rodperson.com mailto:rodper...@rodperson.com wrote:
Fernando Apesteguía wrote:
El 31/01/2014 01:01, Rod Person
rodper...@rodperson.com
mailto:rodper...@rodperson.com escribió:
Hi,
I working on a new new port that requires the
existing port
graphics/py-qt4-svg. If this port is installed on
the sytem already
I get the error below. I have tried this on a
secondary system of
mine and also redports.org http://redports.org
and get the same error. Is there anyway I
can fix this.
This is a like the port I'm working on
http://www.rodperson.com/usr/www/users/pl905/rodperson.com/DL/spyder
Not found. Wrong link?
Sorry, correct link:
http://www.rodperson.com/DL/spyder/
What does make run-depends say? Does it say py-qt4-svg is
installed?
Yes. Same error.
You have an extra PyQt4/ at line
${PYTHON_SITELIBDIR}/PyQt4/PyQt4/QtSvg.so:${PORTSDIR}/graphics/py-qt4-svg \
Thank You!
--
Rod
The lips of wisdom are closed, except to the ears of understanding
- The Kybalion
___
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: net/avahi-app dumps core signal 11 on Freebsd 10 release or freebsd 10 stable SOLVED
On 31/01/2014 18:21, Sergio de Almeida Lenzi wrote: Em Sex, 2014-01-31 às 17:14 +, k...@freebsd.org escreveu: Synopsis: net/avahi-app dumps core signal 11 on Freebsd 10 release or freebsd 10 stable State-Changed-From-To: open-closed State-Changed-By: kwm State-Changed-When: Fri Jan 31 17:14:17 UTC 2014 State-Changed-Why: Committed the disable stack protector, thanks for reporting. http://www.freebsd.org/cgi/query-pr.cgi?pr=186097 Thank you all for the fixed FreeBSD rocks Goes to the helpfull users this time, because I couldn't reproduce this myself. :/ -Koop ___ 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: net/avahi-app core dumps signal 11
On 31 Jan 2014, at 16:50, Thomas Mueller tmuel...@sysgo.com wrote: [current build] nomad:/usr/ports/net/avahi-app# ./work/avahi-0.6.31/avahi-utils/.libs/avahi-browse Segmentation fault (core dumped) nomad:/usr/ports/net/avahi-app# size /usr/local/bin/avahi-browse work/avahi-0.6.31/avahi-utils/.libs/avahi-browse textdata bss dec hex filename 1958411764488 2524862a0 /usr/local/bin/avahi-browse 1958411764488 2524862a0 work/avahi-0.6.31/avahi-utils/.libs/avahi-browse Then there's a difference in the order of libraries in the ldd output, but I don't know if that is relevant: nomad:/usr/ports/net/avahi-app# ldd /usr/local/bin/avahi-browse work/avahi-0.6.31/avahi-utils/.libs/avahi-browse /usr/local/bin/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x80082) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x800a2f000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x800c82000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x800e8e000) libssp.so.0 = /lib/libssp.so.0 (0x801098000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x80129a000) libthr.so.3 = /lib/libthr.so.3 (0x8014a3000) libc.so.7 = /lib/libc.so.7 (0x8016c8000) work/avahi-0.6.31/avahi-utils/.libs/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x80082) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x800a2f000) libthr.so.3 = /lib/libthr.so.3 (0x800c82000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x800ea7000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x8010b3000) libssp.so.0 = /lib/libssp.so.0 (0x8012bd000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x8014bf000) libc.so.7 = /lib/libc.so.7 (0x8016c8000) On a hunch, I downgraded devel/dbus back from 1.6.18 to 1.6.12, now the resulting avahi programs no longer dump core. Hmm, at least I can reproduce it, but the stack trace does not tell me that much: (gdb) run Starting program: /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/./avahi-utils/.libs/avahi-browse [New LWP 101263] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 101263] _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141 141 curthread-cancel_point = 1; (gdb) bt #0 _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141 #1 0x280d0f2d in __open (path=optimized out, flags=optimized out) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390 #2 0x280fef46 in __guard_setup () at /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72 #3 0x280ff182 in ?? () from /lib/libssp.so.0 #4 0x280fe749 in _init () from /lib/libssp.so.0 #5 0x in ?? () (gdb) up #1 0x280d0f2d in __open (path=optimized out, flags=optimized out) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390 390 _thr_cancel_enter(curthread); (gdb) up #2 0x280fef46 in __guard_setup () at /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72 72fd = open (/dev/urandom, O_RDONLY); E.g., __guard_setup() tries to get some random bytes from /dev/urandom (probably for the stack canaries), libthr considers this to be a thread cancellation point, but for some reason the current thread is zeroed out? I don't think this is ever supposed to happen... :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: net/avahi-app core dumps signal 11
On 31 Jan 2014, at 21:35, Dimitry Andric d...@freebsd.org wrote: ... Hmm, at least I can reproduce it, but the stack trace does not tell me that much: (gdb) run Starting program: /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/./avahi-utils/.libs/avahi-browse [New LWP 101263] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 101263] _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141 141 curthread-cancel_point = 1; (gdb) bt #0 _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141 #1 0x280d0f2d in __open (path=optimized out, flags=optimized out) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390 #2 0x280fef46 in __guard_setup () at /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72 #3 0x280ff182 in ?? () from /lib/libssp.so.0 #4 0x280fe749 in _init () from /lib/libssp.so.0 #5 0x in ?? () (gdb) up #1 0x280d0f2d in __open (path=optimized out, flags=optimized out) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390 390 _thr_cancel_enter(curthread); (gdb) up #2 0x280fef46 in __guard_setup () at /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72 72fd = open (/dev/urandom, O_RDONLY); E.g., __guard_setup() tries to get some random bytes from /dev/urandom (probably for the stack canaries), libthr considers this to be a thread cancellation point, but for some reason the current thread is zeroed out? I don't think this is ever supposed to happen... :-) So avahi-browse gets linked as follows (wrapped a little for clarity): cc -I.. -DDEBUG_TRAP=__asm__(\int \$3\) -DDATABASE_FILE=\/usr/local/lib/avahi/service-types.db\ -O2 -pipe -march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing -o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o avahi_browse-stdb.o -L/usr/local/lib ../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so -lpthread /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so ../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp /usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib This executable segfaults, and has the NEEDED libs in the following order: .libs/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x28076000) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x28085000) libthr.so.3 = /lib/libthr.so.3 (0x280cf000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x280f1000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x280fc000) libssp.so.0 = /lib/libssp.so.0 (0x28106000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x28109000) libc.so.7 = /lib/libc.so.7 (0x28112000) When I remove the -lssp from the above linking command line, it is automatically induced anyway, but the executable then gets the following NEEDED libs order: .libs/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x28076000) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x28085000) libthr.so.3 = /lib/libthr.so.3 (0x280cf000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x280f1000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x280fc000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x28106000) libc.so.7 = /lib/libc.so.7 (0x2810f000) libssp.so.0 = /lib/libssp.so.0 (0x28263000) E.g. libssp.so.0 is now located at the end of the list. And _this_ executable runs fine...! If anyone has a good explanation for this, I would be dying to know. :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Any newer latex than latex2e-2003.12_1
The imaxima needs to use latex. But latex2e-2003.12_1 from `pkg seach latex` seems too old. and imaxima always reports latex error when using it. Sinerely! - e^(π.i) + 1 = 0 -- View this message in context: http://freebsd.1045724.n5.nabble.com/Any-newer-latex-than-latex2e-2003-12-1-tp5881914.html Sent from the freebsd-ports mailing list archive at Nabble.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: Samba to web
I was thinking more about some kind of web interface and I came up with some search results: _ smb2www was in the port tree, but removed a couple of years ago; maybe I could try to download and hack it; _ there's SMB Web Client (http://sourceforge.net/projects/smbwebclient/) _ Davenport (which brings WebDav in), _ Others? Before I start digging them all, has anyone faced this task before? Any hint? Why not simply set up a web server with the same auth settings as in Samba? Granted, this isn't exactly what you wanted, and you may end up having to maintain two sets of settings, but that could be a smaller investment than setting up something like one of the above. That said, if you do end up using one of the solutions you mentioned (or similar), it would be great if you could provide some details (perf, your number of users, typical load, etc). Anton ___ 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: net/avahi-app core dumps signal 11
Em Sex, 2014-01-31 às 22:57 +0100, Dimitry Andric escreveu: On 31 Jan 2014, at 21:35, Dimitry Andric d...@freebsd.org wrote: ... Hmm, at least I can reproduce it, but the stack trace does not tell me that much: (gdb) run Starting program: /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/./avahi-utils/.libs/avahi-browse [New LWP 101263] Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 101263] _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141 141 curthread-cancel_point = 1; (gdb) bt #0 _thr_cancel_enter (curthread=0x0) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_cancel.c:141 #1 0x280d0f2d in __open (path=optimized out, flags=optimized out) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390 #2 0x280fef46 in __guard_setup () at /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72 #3 0x280ff182 in ?? () from /lib/libssp.so.0 #4 0x280fe749 in _init () from /lib/libssp.so.0 #5 0x in ?? () (gdb) up #1 0x280d0f2d in __open (path=optimized out, flags=optimized out) at /share/dim/src/freebsd/head-clang34/lib/libthr/thread/thr_syscalls.c:390 390 _thr_cancel_enter(curthread); (gdb) up #2 0x280fef46 in __guard_setup () at /share/dim/src/freebsd/head-clang34/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:72 72fd = open (/dev/urandom, O_RDONLY); E.g., __guard_setup() tries to get some random bytes from /dev/urandom (probably for the stack canaries), libthr considers this to be a thread cancellation point, but for some reason the current thread is zeroed out? I don't think this is ever supposed to happen... :-) So avahi-browse gets linked as follows (wrapped a little for clarity): cc -I.. -DDEBUG_TRAP=__asm__(\int \$3\) -DDATABASE_FILE=\/usr/local/lib/avahi/service-types.db\ -O2 -pipe -march=corei7 -g -fno-strict-aliasing -fstack-protector -std=c99 -Wall -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing -o .libs/avahi-browse avahi_browse-avahi-browse.o avahi_browse-sigint.o avahi_browse-stdb.o -L/usr/local/lib ../avahi-client/.libs/libavahi-client.so /usr/local/lib/libdbus-1.so -lpthread /usr/work/share/dim/ports/net/avahi-app/work/avahi-0.6.31/avahi-common/.libs/libavahi-common.so ../avahi-common/.libs/libavahi-common.so /usr/local/lib/libgdbm.so -lssp /usr/local/lib/libintl.so -pthread -Wl,-rpath -Wl,/usr/local/lib This executable segfaults, and has the NEEDED libs in the following order: .libs/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x28076000) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x28085000) libthr.so.3 = /lib/libthr.so.3 (0x280cf000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x280f1000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x280fc000) libssp.so.0 = /lib/libssp.so.0 (0x28106000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x28109000) libc.so.7 = /lib/libc.so.7 (0x28112000) When I remove the -lssp from the above linking command line, it is automatically induced anyway, but the executable then gets the following NEEDED libs order: .libs/avahi-browse: libavahi-client.so.3 = /usr/local/lib/libavahi-client.so.3 (0x28076000) libdbus-1.so.3 = /usr/local/lib/libdbus-1.so.3 (0x28085000) libthr.so.3 = /lib/libthr.so.3 (0x280cf000) libavahi-common.so.3 = /usr/local/lib/libavahi-common.so.3 (0x280f1000) libgdbm.so.4 = /usr/local/lib/libgdbm.so.4 (0x280fc000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x28106000) libc.so.7 = /lib/libc.so.7 (0x2810f000) libssp.so.0 = /lib/libssp.so.0 (0x28263000) E.g. libssp.so.0 is now located at the end of the list. And _this_ executable runs fine...! If anyone has a good explanation for this, I would be dying to know. :-) -Dimitry Nice catch!!! I am too waiting for the explanation ___ 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
libiconv on 10.0-RELEASE
Seems to be some issues with it: https://forums.freebsd.org/viewtopic.php?f=5t=44644 https://forums.freebsd.org/viewtopic.php?f=5t=44659 And my problem: https://forums.freebsd.org/viewtopic.php?f=5t=44658 Can't do UPDATING: 20130904, libiconv has never been on the system. Not sure whether to allow portmaster to upgrade[*]. Pretty sure something will break if I do. What do you suggest? [*] # portmaster -adwv === All (4) === The following actions will be taken if you choose to proceed: Upgrade php55-iconv-5.5.8 to php55-iconv-5.5.8_1 Install converters/libiconv Upgrade nginx-1.4.4_2,1 to nginx-1.4.4_3,1 Upgrade owncloud-6.0.0a to owncloud-6.0.1 === Proceed? y/n [y] n -- bsdbox.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: libiconv on 10.0-RELEASE
On 02/01/14 07:53, nano wrote: Seems to be some issues with it: https://forums.freebsd.org/viewtopic.php?f=5t=44644 https://forums.freebsd.org/viewtopic.php?f=5t=44659 And my problem: https://forums.freebsd.org/viewtopic.php?f=5t=44658 Can't do UPDATING: 20130904, libiconv has never been on the system. Not sure whether to allow portmaster to upgrade[*]. Pretty sure something will break if I do. What do you suggest? Hi, Since then a new commit has changed things a little, it's r341775 [1] It now allows libiconv to be installed by a few selected ports who really need functionality not available in the base implementation of iconv. [*] # portmaster -adwv === All (4) === The following actions will be taken if you choose to proceed: Upgrade php55-iconv-5.5.8 to php55-iconv-5.5.8_1 Install converters/libiconv Upgrade nginx-1.4.4_2,1 to nginx-1.4.4_3,1 Upgrade owncloud-6.0.0a to owncloud-6.0.1 === Proceed? y/n [y] n From what I see here I think you can allow it to do that without problems for now. I've seen two PRs stating problems with some ports. The PRs I've indicate that, after such a step, glib20 and exim fail to build. These problems need fixing at present. This applies only to ports compiled on the live system, if one is using poudriere or tinderbox they can build anyway(so binary packages have no problems), this happens because when using these software each port is compiled in a clean environment. [1] http://svnweb.freebsd.org/ports?view=revisionrevision=341775 -- Guido Falsi madpi...@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: libiconv on 10.0-RELEASE
On 1/02/2014 6:03 PM, Guido Falsi wrote: On 02/01/14 07:53, nano wrote: Seems to be some issues with it: https://forums.freebsd.org/viewtopic.php?f=5t=44644 https://forums.freebsd.org/viewtopic.php?f=5t=44659 And my problem: https://forums.freebsd.org/viewtopic.php?f=5t=44658 Can't do UPDATING: 20130904, libiconv has never been on the system. Not sure whether to allow portmaster to upgrade[*]. Pretty sure something will break if I do. What do you suggest? Hi, Since then a new commit has changed things a little, it's r341775 [1] It now allows libiconv to be installed by a few selected ports who really need functionality not available in the base implementation of iconv. [*] # portmaster -adwv === All (4) === The following actions will be taken if you choose to proceed: Upgrade php55-iconv-5.5.8 to php55-iconv-5.5.8_1 Install converters/libiconv Upgrade nginx-1.4.4_2,1 to nginx-1.4.4_3,1 Upgrade owncloud-6.0.0a to owncloud-6.0.1 === Proceed? y/n [y] n From what I see here I think you can allow it to do that without problems for now. I've seen two PRs stating problems with some ports. The PRs I've indicate that, after such a step, glib20 and exim fail to build. These problems need fixing at present. This applies only to ports compiled on the live system, if one is using poudriere or tinderbox they can build anyway(so binary packages have no problems), this happens because when using these software each port is compiled in a clean environment. [1] http://svnweb.freebsd.org/ports?view=revisionrevision=341775 Hi, Guido. Thanks for your response. Not sure about this users particular situation, except that it appears they are experiencing some problems compiling libiconv [0]. Another user seems to be experiencing problems (re)installing php5x-iconv, which has rendered something broken [1]. This makes me reluctant to proceed with my upgrades for fear that similar will occur. Also, I'm not usng svn, but portsnap; don't know if it matches r341775. I appreciate your advice, but I think I will wait before updating these ports. Hopefully things get cleaned up a bit. I would not be happy if something breaks. [0] http://forums.freebsd.org/viewtopic.php?f=5t=44644p=248807#p248731 [1] http://forums.freebsd.org/viewtopic.php?f=5t=44659#p248806 -- bsdbox.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: Any newer latex than latex2e-2003.12_1
01.02.2014 07:19, sw2wolf пишет: The imaxima needs to use latex. But latex2e-2003.12_1 from `pkg seach latex` seems too old. and imaxima always reports latex error when using it. There are texlive* ports and (just FYI) freebsd-tex@ maillist. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: libiconv on 10.0-RELEASE
On 02/01/14 08:14, nano wrote: On 1/02/2014 6:03 PM, Guido Falsi wrote: On 02/01/14 07:53, nano wrote: Seems to be some issues with it: https://forums.freebsd.org/viewtopic.php?f=5t=44644 https://forums.freebsd.org/viewtopic.php?f=5t=44659 And my problem: https://forums.freebsd.org/viewtopic.php?f=5t=44658 Can't do UPDATING: 20130904, libiconv has never been on the system. Not sure whether to allow portmaster to upgrade[*]. Pretty sure something will break if I do. What do you suggest? Hi, Since then a new commit has changed things a little, it's r341775 [1] It now allows libiconv to be installed by a few selected ports who really need functionality not available in the base implementation of iconv. [*] # portmaster -adwv === All (4) === The following actions will be taken if you choose to proceed: Upgrade php55-iconv-5.5.8 to php55-iconv-5.5.8_1 Install converters/libiconv Upgrade nginx-1.4.4_2,1 to nginx-1.4.4_3,1 Upgrade owncloud-6.0.0a to owncloud-6.0.1 === Proceed? y/n [y] n From what I see here I think you can allow it to do that without problems for now. I've seen two PRs stating problems with some ports. The PRs I've indicate that, after such a step, glib20 and exim fail to build. These problems need fixing at present. This applies only to ports compiled on the live system, if one is using poudriere or tinderbox they can build anyway(so binary packages have no problems), this happens because when using these software each port is compiled in a clean environment. [1] http://svnweb.freebsd.org/ports?view=revisionrevision=341775 Hi, Guido. Thanks for your response. Not sure about this users particular situation, except that it appears they are experiencing some problems compiling libiconv [0]. Another user seems to be experiencing problems (re)installing php5x-iconv, which has rendered something broken [1]. This makes me reluctant to proceed with my upgrades for fear that similar will occur. Also, I'm not usng svn, but portsnap; don't know if it matches r341775. Don't know at what time you ran portsnap, but, portsnap simply tracks the subversion repository, it's just a little lagged but just by one hour at most, so you most probably have a ports tree post r341775. I appreciate your advice, but I think I will wait before updating these ports. Hopefully things get cleaned up a bit. I would not be happy if something breaks. I understand. I still have not had a good look at r341775 and have only built ports affected by it in poudrirere, and using them as binary packages, which works fine. [0] http://forums.freebsd.org/viewtopic.php?f=5t=44644p=248807#p248731 [1] http://forums.freebsd.org/viewtopic.php?f=5t=44659#p248806 I really don't know what's going on on these user's systems. The error logs they posted have to little backlog to have any idea about what's really causing the problem. For what' I've seen php53-iconv should work fine, but if it's vital to you, you should then wait a little. These problems require some time and trials to fix. Most of the time the problem are the ported software packaging systems which assume FreeBSD has no iconv implementation and expect to find libiconv, or are unable to cope with two iconv implementations being available at the same time. This requires coping with such problems one by one which requires a little time and can't be really managed by automated testing systems, since these problems show up only on live systems. -- Guido Falsi madpi...@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: libiconv on 10.0-RELEASE
On 1/02/2014 6:27 PM, Guido Falsi wrote: On 02/01/14 08:14, nano wrote: On 1/02/2014 6:03 PM, Guido Falsi wrote: Hi, Guido. Thanks for your response. Not sure about this users particular situation, except that it appears they are experiencing some problems compiling libiconv [0]. Another user seems to be experiencing problems (re)installing php5x-iconv, which has rendered something broken [1]. This makes me reluctant to proceed with my upgrades for fear that similar will occur. Also, I'm not usng svn, but portsnap; don't know if it matches r341775. Don't know at what time you ran portsnap, but, portsnap simply tracks the subversion repository, it's just a little lagged but just by one hour at most, so you most probably have a ports tree post r341775. That's good to know. I thought the delay was greater than that. I appreciate your advice, but I think I will wait before updating these ports. Hopefully things get cleaned up a bit. I would not be happy if something breaks. I understand. I still have not had a good look at r341775 and have only built ports affected by it in poudrirere, and using them as binary packages, which works fine. I may create a jail to somewhat emulate my live environment and conduct a test run to see if any problems arise. [0] http://forums.freebsd.org/viewtopic.php?f=5t=44644p=248807#p248731 [1] http://forums.freebsd.org/viewtopic.php?f=5t=44659#p248806 I really don't know what's going on on these user's systems. The error logs they posted have to little backlog to have any idea about what's really causing the problem. For what' I've seen php53-iconv should work fine, but if it's vital to you, you should then wait a little. These problems require some time and trials to fix. Most of the time the problem are the ported software packaging systems which assume FreeBSD has no iconv implementation and expect to find libiconv, or are unable to cope with two iconv implementations being available at the same time. This requires coping with such problems one by one which requires a little time and can't be really managed by automated testing systems, since these problems show up only on live systems. Thanks for the intel. I'm happy to wait, I understand these things take time. I'd rather play it safe than be sorry. The upgrade may succeed without a hitch, but, if not, I'd lose more time to fixing things than waiting in the first place, I suspect. If I do recreate an environment to test, I will notify you of my results. Thanks again. -- bsdbox.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: libiconv on 10.0-RELEASE
On 02/01/14 08:36, nano wrote: I appreciate your advice, but I think I will wait before updating these ports. Hopefully things get cleaned up a bit. I would not be happy if something breaks. I understand. I still have not had a good look at r341775 and have only built ports affected by it in poudrirere, and using them as binary packages, which works fine. I may create a jail to somewhat emulate my live environment and conduct a test run to see if any problems arise. As a personal suggestion, if you have the expertise to do that, you should investigate using poudriere to build your own binary packages repository and upgrade your live, production systems from there. This has the advantage that packages are built in clean environments and you can spot build problems on poudriere before even touching the systems. With such a system you would proceed to upgrade the live systems only after you have a successful package building run. It would not save you from runtime problems (problems which show up only when a program actually runs), but would help for build and packaging problems. Thanks for the intel. I'm happy to wait, I understand these things take time. I'd rather play it safe than be sorry. The upgrade may succeed without a hitch, but, if not, I'd lose more time to fixing things than waiting in the first place, I suspect. If I do recreate an environment to test, I will notify you of my results. Thanks again. Thanks -- Guido Falsi madpi...@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: libiconv on 10.0-RELEASE
On 02/01/14 08:42, Guido Falsi wrote: On 02/01/14 08:36, nano wrote: I appreciate your advice, but I think I will wait before updating these ports. Hopefully things get cleaned up a bit. I would not be happy if something breaks. I understand. I still have not had a good look at r341775 and have only built ports affected by it in poudrirere, and using them as binary packages, which works fine. I may create a jail to somewhat emulate my live environment and conduct a test run to see if any problems arise. As a personal suggestion, if you have the expertise to do that, you should investigate using poudriere to build your own binary packages repository and upgrade your live, production systems from there. Forgot to mention, if you're not using any non standard option in your systems and using only RELEASES, then you could directly use the packages from the official repositories. -- Guido Falsi m...@madpilot.net ___ 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: libiconv on 10.0-RELEASE
On 1/02/2014 6:45 PM, Guido Falsi wrote: On 02/01/14 08:42, Guido Falsi wrote: On 02/01/14 08:36, nano wrote: I appreciate your advice, but I think I will wait before updating these ports. Hopefully things get cleaned up a bit. I would not be happy if something breaks. I understand. I still have not had a good look at r341775 and have only built ports affected by it in poudrirere, and using them as binary packages, which works fine. I may create a jail to somewhat emulate my live environment and conduct a test run to see if any problems arise. As a personal suggestion, if you have the expertise to do that, you should investigate using poudriere to build your own binary packages repository and upgrade your live, production systems from there. I do intend to setup my own repository with Poudriere but have been delaying for some unknown reason (read: laziness). In fact, I think I will do this in the next few days. It will make things much more efficient. Forgot to mention, if you're not using any non standard option in your systems and using only RELEASES, then you could directly use the packages from the official repositories. I try to use packages where I can, but often programs require non-default build options so I have to build from ports. I'm often warned to not mix ports with packages; what is your take on this? -- bsdbox.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: libiconv on 10.0-RELEASE
On 02/01/14 08:50, nano wrote: I try to use packages where I can, but often programs require non-default build options so I have to build from ports. I'm often warned to not mix ports with packages; what is your take on this? It can work but better avoid it. It's not as bad as crossing the streams but could cause problems. Difficult to foresee what kind of problems and why because it depends on too many factors. I know users who have always been mixing a few hand build ports with a mostly package system without problems. It can be done if one knows what he's doing. But it's not the officially supported way of doing things. -- Guido Falsi madpi...@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: libiconv on 10.0-RELEASE
On 1/02/2014 6:54 PM, Guido Falsi wrote: On 02/01/14 08:50, nano wrote: I try to use packages where I can, but often programs require non-default build options so I have to build from ports. I'm often warned to not mix ports with packages; what is your take on this? It can work but better avoid it. It's not as bad as crossing the streams but could cause problems. Difficult to foresee what kind of problems and why because it depends on too many factors. I know users who have always been mixing a few hand build ports with a mostly package system without problems. It can be done if one knows what he's doing. But it's not the officially supported way of doing things. I'll stick to ports till building my own repository then. Thanks again, Guido. I appreciate all your advice. -- bsdbox.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
