ports/155971: [PATCH] databases/sqlite3: always enable EXTENSIONS

Matthias Andree mandree at FreeBSD.org
Mon Mar 28 18:19:44 UTC 2011


Beat Gätzi:

> Wouldn't that create a conflict between sqlite3 and the new slave port? In
> this case that isn't the solution too.
> Is there a way to query sqlite3 to find out if it was build with loadable
> extensions? If yes, we could query that in the firefox port and set BROKEN
> if this isn't the case.

Indeed I'd prefer IGNORE or BROKEN, but we can't catch that so early --
and particularly not without forking processes while the Makefile is
being parsed.

The test would erroneously fail if py*-sqlite3 and/or sqlite3 is not
installed before you attempt the build, but got installed only as part
of firefox's depends - so we cannot do this earlier than post depends,
f. i. in pre-build.

There's a way that work without python (needed because python may only
be installed as firefox's dependency), and that is:

  objdump -R ${LOCALBASE}/libsqlite3.so | grep -w sqlite3_load_extension

We can additionally try grepping ${PORT_DBDIR}/sqlite3/options and/or
the libfile, but again, neither is guaranteed to exist when you "make"
firefox's Makefile - and we don't want != lines.


How about the attached patch to www/firefox?  It performs this check in
pre-everything (in case sqlite3 is already installed) and again in
pre-build (if it got installed in the 'make depends' stage).

As a side effect, it also removes the != line (for pthread library
extraction) as per the recent portlint warning URL, so that reading the
Makefile doesn't fork a new process.

Works for me, but please double-check.

Best
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-www-firefox-PGO.patch
Type: text/x-patch
Size: 5544 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-gecko/attachments/20110328/9acb6f53/check-www-firefox-PGO-0001.bin


More information about the freebsd-gecko mailing list