1.9.0_4net-imΣ=4 1.9.0_4Version of this port present on the latest quarterly branch.
BROKEN: ld: error: undefined symbol: boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, bool) DEPRECATED: Abandonware, project is dead This port expired on: 2022-06-20 IGNORE: is marked as broken: ld: error: undefined symbol: boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, bool)
There is no maintainer for this port.
Any concerns regarding this port should be directed to the FreeBSD Ports mailing list via ports@FreeBSD.org
This is an unofficial ICQ clone, written in C++.
It is in no way endorsed by Mirabilis, and now is the most full-featured
ICQ-compatible program with the exception of Java ICQ.
LICENSE: GPL2 or later with execption to link with OpenSSL
WWW: http://www.licq.org/
===> The following configuration options are available for licq-base-1.9.0_4:
GPGME=on: Build support for gpgme
NLS=on: Native Language Support
===> Use 'make config' to modify these settings
In order to actually use licq, at least one plugin port needs to be installed.
Currently they include: licq-qt-gui, licq-kde-gui and several others.
Check the net category to find them.
cleanup: Remove expired ports:
2022-06-20 net-im/licq: Abandonware, project is dead
Remove these ports too which were part of net-im/licq:
- net-im/licq-icq
- net-im/licq-jabber
- net-im/licq-osd
- net-im/licq-qt-gui
net-im/licq: apply googletest patches which fix null pointer accesses
During an exp-run for llvm 12 (see bug 255570), it turned out that
net-im/licq does not build with clang 12.0.0:
[ 92%] Running unit test
cd /wrkdirs/usr/ports/net-im/licq/work/.build/src && /usr/local/bin/ctest
Test project /wrkdirs/usr/ports/net-im/licq/work/.build/src
Start 1: licq
1/1 Test #1: licq .............................***Exception: SegFault 0.03 sec
This is due to licq using a relatively ancient version of googletest,
which has a few issues with more modern compilers. In particular, it
does not handle mocking methods with move-only return types, and in the
case of this port, this leads to a null pointer access and consequently
a segfault.
To fix the null pointer accesses, apply a few upstream googletest
commits.
Approved by: maintainer timeout (2 weeks)
PR: 255915
MFH: 2021Q2
Make ninja opt-out in cmake.mk
Using ninja instead of make (1) can lead to significant speed ups while
building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
Update security/gpgme-* to 1.8.0
In this version, libgpgme-pthread.so has been removed in favor of just
using libgpgme.so as the thread-safe library. PORTREVISION has been
bumped on all ports depending on security/gpgme so that any that may have
linked to -lgpgme-pthread will link to -lgpgme instead.
The Python module provided by security/py-gpgme has been renamed upstream
from pyme3 to gpg. This removes the conflict with security/py-pyme,
although security/py-gpgme is still the direct replacement of that
module.
Uses/iconv.mk: Set iconv-related CMake variables.
The way we deal with iconv in base and ports across different FreeBSD
releases is complicated: 9.x does not have iconv.h in base, 10.1 has it with
a different prototype for iconv(3) and later versions have the right
iconv(3) prototype. And, in some cases (USES=iconv:{translit,wchar_t}), we
must always use the libiconv port.
This is why there are so many checks in Uses/iconv.mk: we need to know the
situation we currently have in order to decide whether to pull iconv from
converters/libiconv, whether to just use its header (and pull the library
from base) or whether to use everything from base.
r384038 adjusted several CMake-based ports, but did so in a way that was not
very scalable and required a few intrusive patches to some ports. Most ports
(Only the first 15 lines of the commit message are shown above )
converters/libiconv:
- Remove const qualifier from iconv(3) to match POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
- Patch iconv.h to expose more GNU extensions when LIBICONV_PLUG is
defined because the base system iconv supports these extensions too.
Add/remove patches to/from ports to call iconv with non-const arguments.
This breaks some ports on FreeBSD 10 because base system iconv.h still has
the const qualifier. Fix this by letting USES=iconv add a build dependency
on converters/libiconv so ports can use its iconv.h (with LIBICONV_PLUG
defined) instead of the base system iconv.h.
This exposed some ports that link with libiconv when it is available instead
of using libc iconv. In these cases one of the following changes has been
(Only the first 15 lines of the commit message are shown above )
Remove indefinite articles and trailing periods from COMMENT, plus minor
COMMENT typos and surrounding whitespace fixes. A few Makefiles where not
included as they contain Latin-1 characters that break the Phabricator
workflow. Category N.
CR: D307
Approved by: portmgr (bapt)
- Make ports use the libc provided iconv implementation on 10-CURRENT
after r254273
- Fix a bunch of ports to properly work after this
- Mark converters/libiconv as IGNORE for systems with iconv in libc
Reviewed by: bapt
Approved by: portmgr (bapt)
Discussed with: bapt, bsam (who both contributed ideas and code)
Deprecate md5 in favour of sha256 checksums. md5 checksums will no longer
be generated or checked, and will be silently ignored for now. Also,
generalize the MD5_FILE macro to DISTINFO_FILO.
PR: 149657
Submitted by: rene
Approved by: portmgr
Tested on: pointyhat i386 7-exp
- Update boost to 1.39
- Split boost port to separate components, with boost-all metaport
PR: ports/137054
Submitted by: Alexander Churanov <churanov.port.maintainer@gmail.com>
(maintainer)
