Re: Selecting at least one option out of multiple groups
On 02/01/15 00:55, Scot Hetzel wrote: > On Wed, Jan 28, 2015 at 3:31 AM, Elizabeth Myers > wrote: >> Hello, >> >> I am porting a piece of software (purple-plugin-pack) to FreeBSD. It >> contains numerous plugins for Pidgin all under one pack (over 50). They > > Is this going to be one port that installs over 50 plugins (based on > what is selected), or is it going to be over 50+1 ports? I was thinking one port, since they come as a pack, and the idea of adding over 50 ports to the tree is... well, that's 50 ports I'd have to submit. That's quite an undertaking. > +1 port (pidgin-purple-plugin-pack) [meta-port (see x11/kde4 for an example)] > - allows you to select which purple plugins to install (depends on > selected pidgin-purple-plugin-* ports) If there's a meta port, I guess it wouldn't matter if no plugins were selected by it? I still think it'd be ideal to categorise them in the meta port, at least by protocol/general use. > over 50 ports > - individual port for each plugin (i.e. > graphics/pidgin-purple-plugin-album > net-im/pidgin-purple-plugin-autoprofile > net-im/pidgin-purple-plugin-autoreply > net-im/pidgin-purple-plugin-awaynotify > shells/pidgin-purple-plugin-bash > ...) > - allows individual plugins to be installed/de-installed without > having to re-install the purple-plugin-pack This is definitely appealing, I will admit. > If you go the over 50+1 ports route, each port could have it's own > option settings. So far none of the plugins in the pack have their own option settings, as far as I can tell. This does leave open the possibility, though. -- Cheers, Elizabeth Myers ___ 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"
[NEW PORT] x11-fonts/symbola - a Unicode 7.0 font
Hello, I'm posting this in case the bugzilla issue got lost in the noise. I know four days is a bit hasty, though *puts on flameproof garments*. See issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197090 This font also contains numerous emoji, which is what I use for emoji support here. Not in colour, of course, but it's still better than nothing. If anyone has any comments/rotten tomatoes to pelt at me, go right on ahead. -- Cheers, Elizabeth ___ 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/isc-dhcp42-server and ldap support
Dear FreeBSD friends, I like to install net/isc-dhcp42-server with LDAP and LDAP_SSL support. However upon compilation, I received the following error message: gmake[3]: Entering directory '/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.7/omapip' cc -O2 -pipe -fPIC -fstack-protector -DLDAP_DEPRECATED -fno-strict-aliasing -I../bind/include -Wl,-rpath,/usr/lib:/usr/local/lib -Wl,-rpath,/usr/lib:/usr/local/lib -Wl,-rpath,/usr/lib:/usr/local/lib -Wl,-rpath,/usr/lib:/usr/local/lib -fstack-protector -o svtest test.o libomapi.a ../bind/lib/libdns.a ../bind/lib/libisc.a -llber -lldap -L/usr/local/lib -lssl libomapi.a(buffer.o): In function `omapi_connection_copyin': buffer.c:(.text+0x76b): undefined reference to `isc__socket_fdwatchpoke' libomapi.a(dispatch.o): In function `omapi_register_io_object': dispatch.c:(.text+0x3aa): undefined reference to `isc__socket_fdwatchcreate' libomapi.a(dispatch.o): In function `omapi_reregister_io_object': dispatch.c:(.text+0x50d): undefined reference to `isc__socket_fdwatchpoke' libomapi.a(dispatch.o): In function `omapi_unregister_io_object': dispatch.c:(.text+0x677): undefined reference to `isc__socket_cancel' dispatch.c:(.text+0x67f): undefined reference to `isc__socket_detach' libomapi.a(isclib.o): In function `isclib_cleanup': isclib.c:(.text+0x27): undefined reference to `isc__task_shutdown' isclib.c:(.text+0x30): undefined reference to `isc__task_detach' isclib.c:(.text+0x40): undefined reference to `isc__timermgr_destroy' isclib.c:(.text+0x50): undefined reference to `isc__socketmgr_destroy' isclib.c:(.text+0x60): undefined reference to `isc__taskmgr_destroy' isclib.c:(.text+0x6f): undefined reference to `isc__app_ctxfinish' isclib.c:(.text+0x86): undefined reference to `isc__appctx_destroy' isclib.c:(.text+0x9e): undefined reference to `isc__mem_detach' libomapi.a(isclib.o): In function `dhcp_context_create': isclib.c:(.text+0x10b): undefined reference to `isc__mem_create' isclib.c:(.text+0x12c): undefined reference to `isc__appctx_create' isclib.c:(.text+0x13d): undefined reference to `isc__app_ctxstart' isclib.c:(.text+0x1a6): undefined reference to `isc__task_create' libomapi.a(isclib.o): In function `dhcp_signal_handler': isclib.c:(.text+0x446): undefined reference to `isc__app_ctxsuspend' cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [svtest] Error 1 Makefile:390: recipe for target 'svtest' failed gmake[3]: Leaving directory '/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.7/omapip' gmake[2]: *** [all-recursive] Error 1 Makefile:412: recipe for target 'all-recursive' failed gmake[2]: Leaving directory '/usr/ports/net/isc-dhcp42-server/work/dhcp-4.2.7' *** Error code 1 Stop. make[1]: stopped in /usr/ports/net/isc-dhcp42-server *** Error code 1 Stop. make: stopped in /usr/ports/net/isc-dhcp42-server How can I compile isc-dhcp42-server with LDAP and LDAP_SSL support? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.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: testing the value of ${CXX} in ports Makefile
On 31 Jan, Jan Beich wrote: > Don Lewis writes: > >> PORTNAME=junk >> PORTVERSION= 0.0.0 >> CATEGORIES= devel >> DISTFILES= >> >> MAINTAINER= truck...@freebsd.org >> COMMENT= junk >> >> USE_GCC= 4.9+ >> >> .include >> >> post-patch: >> echo CXX=${CXX} >> .if ${CXX} == g++49 > > This idiom may lead to crashes. According to the wiki[1] mixing > libstdc++ and libc++ is only supported when both are linked against > libcxxrt. lang/gcc by default use libsupc++, so you'd have to add Yeah, been there, done that. I found this out firsthand on FreeBSD 10 when I pulled in a dependency that was compiled with clang. > USES= compiler:gcc-c++11-lib > > to force the port use devel/libc++. At least for now I'm happy to stick with libstdc++. The code currently doesn't even compile with clang, hence USES_GCC=yes. If I USES= compiler:gcc-c++11-lib > Also, the following wouldn't work > > .if ${CHOSEN_COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} == 49 > > because COMPILER_VERSION or COMPILER_FEATURES are evaluated against > COMPILER_TYPE, not CHOSEN_COMPILER_TYPE. Yup, that appears to be the case. > [1] > https://wiki.freebsd.org/NewC++Stack#Mixing_Libraries_using_Libc.2B-.2B-_and_Libstdc.2B-.2B- USES=compiler:gcc-c++11-lib allows me to force GCC, but it looks like I always get the default version from ports and USE_GCC is ignored. CXX is still not updated early enough. PORTNAME= junk PORTVERSION=0.0.0 CATEGORIES= devel DISTFILES= MAINTAINER= truck...@freebsd.org COMMENT=junk USES= compiler:gcc-c++11-lib .include post-patch: @echo CXX=${CXX} @echo GCC_DEFAULT=${GCC_DEFAULT} @echo CHOSEN_COMPILER_TYPE=${CHOSEN_COMPILER_TYPE} .if ${CXX} == g++48 @echo g++48 was detected .endif .if ${CXX} == c++ @echo .if thinks CXX is still clang .endif .include # make patch ===> Patching for junk-0.0.0 CXX=g++48 GCC_DEFAULT=4.8 CHOSEN_COMPILER_TYPE=gcc .if thinks CXX is still clang ___ 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: testing the value of ${CXX} in ports Makefile
On 31 Jan, Shane Ambler wrote: > On 31/01/2015 10:55, Don Lewis wrote: >> On 31 Jan, Shane Ambler wrote: >>> On 30/01/2015 14:13, Don Lewis wrote: > >> post-patch: >> @echo CXX=${CXX} >> @echo GCC_DEFAULT=${GCC_DEFAULT} >> .if ${CHOSEN_COMPILER_TYPE} == gcc and ${COMPILER_VERSION} == 49 >> @echo g++49 was detected >> .else >> @echo g++49 was not detected >> .endif >> >> # make patch >> make: "/usr/ports/editors/junk/Makefile" line 17: Malformed conditional >> (${CHOSEN_COMPILER_TYPE} == gcc and ${COMPILER_VERSION} == 49) >> make: Fatal errors encountered -- cannot continue > > yeah my bad - don't know why I typed `and` instead of `&&` > >>> You may also want to consider patching with - >>> >>> #if (__GNUC__ == 4) && (__GNUC_MINOR__ == 9) >>> // 4.9 specific changes >>> #endif >> >> That would work if I was patching C or C++ code, but I'm actually patching >> a file that is used to set the the -O value for CFLAGS. The build stuff >> in the port is pretty strange and uses different optimization levels for >> for different parts of the build and one of choices that it makes >> triggers a code generation bug in gcc 4.9. > > What is the build system used? > > Can the build files do something like > > COMPVERS=`${CXX} --version | grep -e gcc -e 4.9` > if [ ! -z $COMPVERS ] >${CXX} -O2 > else >${CXX} -Os > fi As near as I can figure out, it's a mixture of gmake and dmake kicked off by a perl wrapper and both flavors have to be patched. It just seems easier to use four lines of shell code to change two instances of -Os than to try to figure out how to get two different flavors of make to do what I want (and verify that it actually works). I could maybe use the time I save on creating a gcc bug report and getting the compiler fixed. ___ 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: Use GCC only for specific ARCH
On 10/12/2014 7:11 PM, Daniel Morante wrote: > I have a port that builds fine on a 9.3 amd64, but on 9.3 i386 it > fails on this line: > > inline int64 GetMaxMoney() { return nBestHeight <= HARDFORK_HEIGHT_1 ? > 500 * COIN : 250 * COIN; } > > With the following error: > > "integer constant is too large for 'long' type" > > If I add "USE_GCC=yes" to the port's Makefile, it builds successfully > on i386. I'd like to apply this 'fix' only to the 32-bit platform so > I did the following: > > .if ${ARCH} == "i386" > USE_GCC=yes > .endif > > Is that the 'correct' way to do things? > > The port can be found here: > https://github.com/tuaris/FreeBSD-Coin-Ports/blob/master/ports/kittehcoin/Makefile#L80 > > Daniel, In addition to USE_GCC=yes in your make.conf, you'll also need to add to /etc/libmap.conf libgcc_s.so.1 gcc48/libgcc_s.so.1 libgomp.so.1 gcc48/libgomp.so.1 libobjc.so.4 gcc48/libobjc.so.2 libssp.so.0 gcc48/libssp.so.0 libstdc++.so.6gcc48/libstdc++.so.6 # I don't believe I use these, but to easily avoid further troubleshooting, they're here libatomic.so.1gcc48/libatomic.so.1 libgomp.so.1 gcc48gcc48/libgomp.so.1 libquadmath.so.0 gcc48/libquadmath.so.0 So with libmap.conf configured, a simple cd /usr/ports/security/nmap && make clean deinstall package; pkg add nmap-6.47.txz results in, I've added the '<' for reference: # ldd /usr/local/bin/nmap /usr/local/bin/nmap: libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80095d000) libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0x800bd) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800e15000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801081000) libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x80148c000) libm.so.5 => /lib/libm.so.5 (0x801796000) libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x8019bd000) << libc.so.7 => /lib/libc.so.7 (0x801bd2000) libthr.so.3 => /lib/libthr.so.3 (0x801f76000) without libmap.conf you'll have /usr/local/bin/nmap: libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80095d000) libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0x800bd) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x800e15000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801081000) libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x80148c000) libm.so.5 => /lib/libm.so.5 (0x801796000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8019bd000) << libc.so.7 => /lib/libc.so.7 (0x801bcb000) libthr.so.3 => /lib/libthr.so.3 (0x801f6f000) Aside: I came across this as I was getting 'bus error' while building /usr/ports/security/p5-IO-Socket-SSL with march=prescott. As it turns out, the problem was repeatable with echo 'eval { require Net::SSLeay; $Net::SSLeay::trace=1; Net::SSLeay::randomize(); };' > /tmp/a; perl /tmp/a bus error Rebuilding SSLEAY and perl5.20 with gcc enabled me to continue working, without changing my CFLAGS statement CFLAGS= -O2 -pipe -g0 -ggdb0 -march=prescott -mtune=prescott -fno-strict-aliasing I initially tried to turn off stack-protector, however even applying to /etc/make.conf WITHOUT_SSP=yes SSP_UNSAFE=yes perl5.20 continued to add --stack-protector to CFLAGS. Yes, I even mv bsd.ssp.mk bsd.ssp.mk-hide; touch bsd.ssp.mk it was simply too elusive... I should mention that I added to make.conf the following as I also use ccache (3.2) CC:=/usr/local/libexec/ccache/gcc48 cc:=/usr/local/libexec/ccache/gcc48 gcc48:=/usr/local/libexec/ccache/gcc48 CXX:=/usr/local/libexec/ccache/g++48 c++:=/usr/local/libexec/ccache/g++48 g++48:=/usr/local/libexec/ccache/g++48 I suspect that I should only need CC and CXX, but I'm not very technical. Thanks for your hint about USE_GCC=yes in make.conf, along with https://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html It started me down an alternate road :) After clearing the ccache and /var/ports, my first attempt of using gcc48 using -march pentium3 (on i386) and core2 (on amd64), failed to build 7 ports; interestingly using clang they successfully built all 655 packages. (??) Regards, Dewayne. -- For the talkers: “The superior man acts before he speaks, and afterwards speaks according to his action.” For everyone else: “Life is really simple, but we insist on making it complicated.” ___ 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: Use GCC only for specific ARCH
On 10 Dec 2014, at 09:29, Christoph Moench-Tegeder wrote: > > ## Daniel Morante (dan...@morante.net): > >> I have a port that builds fine on a 9.3 amd64, but on 9.3 i386 it fails >> on this line: >> >> inline int64 GetMaxMoney() { return nBestHeight <= HARDFORK_HEIGHT_1 ? >> 500 * COIN : 250 * COIN; } >> >> With the following error: >> >> "integer constant is too large for 'long' type" > > I believe the fix is to make sure those constants are interpreted as > "long long", e.g. by post-fixing LL. Or by using the ugly-looking, but more portable INT64_C() macro. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail