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
