Re: libtool doesn't create .so
On Fri, Mar 19, 2010 at 8:37 PM, Stuart Henderson s...@spacehopper.org wrote: Here's what I have up to now. Not tested yet but I thought I'd send something out rather than sit on it... Do I need to be running current? I tried $ cd libmonetdb $ make clean ... $ make configure but got the output below. $ cd .. $ pwd /usr/ports/databases/monetdb $ make ... output very similar to output pasted below. And finally: $ cd .. $ pwd /usr/ports/databases/monetdb $ make libmonetdb `libmonetdb' is up to date. $ I wonder if Makefile.inc is not getting pulled in b/c it doesn't got get gm4 or autoconf 2.62. I get this feeling this is a hard app to port. Thanks, m # make clean === Cleaning for libmonetdb-1.36.1 # make configure === libmonetdb-1.36.1 depends on: m4-* - found === libmonetdb-1.36.1 depends on: metaauto-* - found === libmonetdb-1.36.1 depends on: autoconf-2.60 - found === libmonetdb-1.36.1 depends on: gmake-* - found === libmonetdb-1.36.1 depends on: libtool-* - found === libmonetdb-1.36.1 depends on: bzip2-* - found === libmonetdb-1.36.1 depends on: bzip2-* - found === libmonetdb-1.36.1 depends on: libiconv-* - found === Verifying specs: bz2 iconv.=2 bz2 iconv.=2 crypto pthread ssl z crypto pthread ssl z === found bz2.10.4 iconv.6.0 crypto.18.0 pthread.11.1 ssl.15.0 z.4.1 === Checking files for libmonetdb-1.36.1 `/usr/ports/distfiles/MonetDB-1.36.1.tar.bz2' is up to date. (SHA256) MonetDB-1.36.1.tar.bz2: OK === Extracting for libmonetdb-1.36.1 === Patching for libmonetdb-1.36.1 Can't find autoconf 2.60 signature in /usr/ports/obj/libmonetdb-1.36.1/MonetDB-1.36.1/configure: # Generated by GNU Autoconf 2.63 for MonetDB Common 1.36.1. generated by GNU Autoconf 2.63 generated by GNU Autoconf 2.63. Invocation command line was generated by GNU Autoconf 2.63. Invocation command line was configured by $0, generated by GNU Autoconf 2.63, Running autoconf-2.60 in /usr/ports/obj/libmonetdb-1.36.1/MonetDB-1.36.1 aclocal.m4:16: warning: this file was generated for autoconf 2.63. You have another version of autoconf. It may work, but is not guaranteed to. If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'. configure.in:32: error: Autoconf version 2.62 or higher is required aclocal.m4:446: AM_INIT_AUTOMAKE is expanded from... configure.in:32: the top level autom4te-2.60: /usr/local/bin/gm4 failed with exit status: 63 *** Error code 63 Stop in /usr/ports/databases/monetdb/libmonetdb (line 2091 of /usr/ports/infrastructure/mk/bsd.port.mk). # make autoreconf make: don't know how to make autoreconf. Stop in /usr/ports/databases/monetdb/libmonetdb. #
Re: libtool doesn't create .so
On Tue, Mar 23, 2010 at 6:10 PM, Marc Espie es...@nerim.net wrote: Yes, very current. Can I use a snapshot? m
Re: libtool doesn't create .so
On Fri, Mar 19, 2010 at 8:37 PM, Stuart Henderson s...@spacehopper.org wrote: Here's what I have up to now. Not tested yet but I thought I'd send something out rather than sit on it... Thanks for your help. You did a ton of work. I'm working on a patch for the dynamic loading issue, and when I get that done I'll add it to your tarball. The machine I'm using is really slow, so it will take me a while to put it all together. m
Re: libtool doesn't create .so
On Thu, Mar 18, 2010 at 12:59 PM, Mark Bucciarelli mkb...@gmail.com wrote:
How do I get the symbolic links generated
from .so.version to .so?
What I've learned:
* If my test code is right (see below), dlopen(libbat.so)
and dlopen(/usr/local/lib/libbat.so.1.34) do the
same thing on OpenBSD.
* library_names_spec determines what symbolic links
libtool makes, and OpenBSD and Linux have different
values for this variable.
* a similar topic came up on this list five years ago [1]
So, it seems to me the correct approach is to patch
monetdb to skip the call to open() and let dlopen()
do it's thing.
Does this make sense? (Dynamic loading is new
to me.)
I'll ping upstream to ask why they call open() before
calling dlopen(). I can't think of what value it adds.
Thanks,
m
[1] http://www.mail-archive.com/ports@openbsd.org/msg02600.html
#include dlfcn.h
#include stdio.h
int
main(void)
{
void*handle;
char*fns[] = {
libbat.so,
/usr/local/lib/libbat.so.1.34,
libbat.so.1.34,
libbat.so.1,
0
};
char**fn;
for (fn = fns; *fn; fn++) {
fprintf(stderr, handle = %p for %s\n, dlopen(*fn,
RTLD_NOW), *fn);
dlclose(handle);
}
return 0;
}
Re: libtool doesn't create .so
On Fri, Mar 19, 2010 at 11:05 AM, Stuart Henderson s...@spacehopper.org wrote: There are some problems with SSL checks which need configure Maybe an upstream fix didn't make it into the Feb2010 tarballs. There was a patch to buildtools/conf/MonetDB.m4 applied to HEAD to fix issues I was having with finding openssl. ref: http://sourceforge.net/tracker/index.php?func=detailaid=2914578group_id=56967atid=482468 m
Re: how to fetch multiple archives?
On Thu, Mar 18, 2010 at 1:20 AM, J.C. Roberts list-...@designtools.org wrote: The size is not that bad by comparison and dealing with a single file is more reliable dealing with a whole bunch of small files, I tried building from the large archive, but the directory tree after make expand didn't match what the ports makefile expected. Manually, I would type something like this: $ cd /usr/ports/obj/MonetDB*/MonetDB*/MonetDB/MonetDB/ $ ./configure $ gmake $ gmake install $ cd ../../ $ cd clients/clients $ ./configure etc. I got as far as adding a do-build target that wasn't triggered. (Maybe I used the wrong hook name?) Anyway, it was getting complex. Upstream also provides a huge shell script in the big archive but I never build that way myself and it has lots and lots of logic in it I'll never use. Using tiny and simple Makefiles seems cleaner and easier to maintian. if upstream has a habit of changing/re-releasing files under the same file name (e.g. screws up chksum and forces the project to mirror the old version after release). I spot checked a few releases and they seem good about versioning. Thanks, m
Re: libtool doesn't create .so
On Wed, Mar 17, 2010 at 10:37 AM, Stuart Henderson s...@spacehopper.org wrote: I suggest starting by trying to create a port So make install of monetdb/monetdb runs without error. But after the install, when I list the LIB_SHARED files in /usr/local/lib, there is still no .so libs, only files with the .so.version. The app logic open()'s the file with the plain .so extension. How do I get the symbolic links generated from .so.version to .so? Makefile enclosed below. Thanks, m # $OpenBSD: Makefile.template,v 1.55 2008/08/23 15:28:00 ajacoutot Exp $ COMMENT = column store database (core libraries) DISTNAME = MonetDB-1.36.1 CATEGORIES =databases/monetdb MASTER_SITES = http://monetdb.cwi.nl/downloads/sources/Feb2010/ HOMEPAGE = http://monetdb.cwi.nl/Home/ MAINTAINER =Mark Bucciarelli mkb...@gmail.com # #MonetDB Public License Version 1.1 # #This License is a derivative of the Mozilla Public License #(MPL) Version 1.1, where the difference is that all references #to Mozilla and Netscape have been changed to MonetDB, #and that the License has been made subject to the laws of #The Netherlands. # # ref: http://monetdb.cwi.nl/Legal/MonetDBLicense-1.1.html # PERMIT_PACKAGE_CDROM = Yes PERMIT_PACKAGE_FTP =Yes PERMIT_DISTFILES_CDROM =Yes PERMIT_DISTFILES_FTP = Yes SEPARATE_BUILD =concurrent (build simultaneously on all arches) USE_X11 = No USE_GMAKE = Yes USE_LIBTOOL = Yes CONFIGURE_STYLE = gnu CONFIGURE_ARGS += --enable-strict CONFIGURE_ARGS += --enable-assert CONFIGURE_ARGS += --enable-debug CONFIGURE_ARGS += --enable-profile # SHARED_LIBS+= libname obsd version # orig version SHARED_LIBS += mutils 1.36 # .1.36 SHARED_LIBS += stream 1.36 # .1.36 SHARED_LIBS += bat 1.36 # .1.36 .include bsd.port.mk
Re: libtool doesn't create .so
On Wed, Mar 17, 2010 at 10:37 AM, Stuart Henderson s...@spacehopper.org wrote: I suggest starting by trying to create a port OK, thanks. m
how to fetch multiple archives?
Working my way through the ports manual and
it didn't take me too long to get stuck. :)
I can get MonetDB sources either as one big bz2
or lzma file, or as multiple tar.gz archives.
Further complicating things is the version number
is not the same across the different tar.gz files.
This is what I tried, but I think it's wrong---I think
PKGNAME is just for building packages, not for
retreiving sources.
V= 1.36.1
DISTNAME= MonetDB-${V}
PKGNAME-main= MonetDB-${V}
PKGNAME-clients=MonetDB-client-${V}
PKGNAME-monetdb5= MonetDB5-server-5.18.1
PKGNAME-sql=MonetDB-SQL-2.36.1
DIST_SUBDIR = monetdb
CATEGORIES= databases
MASTER_SITES= http://monetdb.cwi.nl/downloads/sources/Feb2010/
Thanks,
m
Re: how to fetch multiple archives?
On Wed, Mar 17, 2010 at 1:45 PM, Jolan Luff jo...@gormsby.com wrote: You need to manually set DISTFILES instead. Is this variable documented somewhere? m
Re: how to fetch multiple archives?
On Wed, Mar 17, 2010 at 2:41 PM, Stuart Henderson s...@spacehopper.org wrote: DISTNAME = MonetDB-Feb2010-SuperBall EXTRACT_SUFX = .tar.bz2 It's massive. === Checking files for MonetDB-Feb2010-SuperBall Fetch http://monetdb.cwi.nl/downloads/sources/Feb2010/MonetDB-Feb2010-SuperBall.tar.bz2 MonetDB-Feb2010-SuperB... 44% |*** | 24228 KB 04:22 ETA /usr: write failed, file system is full ftp: Writing MonetDB-Feb2010-SuperBall.tar.bz2: No space left on device :( m
typo in porting guide: pobj -- obj
http://www.tw.openbsd.org/faq/ports/guide.html On 4.6, make extract puts sources in /usr/ports/obj not /usr/ports/pobj Thanks, m
Re: how to fetch multiple archives?
On Wed, Mar 17, 2010 at 6:27 PM, Stuart Henderson s...@spacehopper.org wrote: Hmm. If these can be built independently maybe the best way is separated with a layout like this; /usr/ports/databases/monetdb /usr/ports/databases/monetdb/monetdb /usr/ports/databases/monetdb/monetdb-sql /usr/ports/databases/monetdb/monetdb-xquery ... Thanks, this was very helpful. Now make build triggers configure and gmake with a really simple Makefile. There are dependencies in the build order monetdb -- clients -- MonetDB5 -- sql but I expect I can put these in the various Makefiles and it will just work. m
monetdb
Hi, I've been working on getting MonetDB to build on OpenBSD. I'm not sure I'll get as far as building a port, but my patches are getting accepted [1] so at least I can get their source tree to build cleanly on OpenBSD. I've hit a couple things I can't figure out. One is related to auto-tools crap. After I run their bootstrap script, I have to edit the configure.sh script so that every instance of -lssl is replaced by -lssl -lcrypto. In a comment in the bug report [2], a MonetDB dev said weird this is autoconf generated code. I'm hoping this is a fairly common issue with ports that use openssl. I grepped through the MonetDB code, but couldn't find a .m4, a .in, or .am file that creates this test. I'm pretty stuck on this one. The other issue is that they use a %pure_parser statement in their yacc code. Is this specific to bison? The OpenBSD 4.6 yacc failed to compile that line. If it is bison-specific, do they need to update their build to call bison or is there a way I can set a know to tell OpenBSD to use bison and not yacc. Thanks, Mark [1] http://sourceforge.net/tracker/?func=detailaid=2920265group_id=56967atid=482468 [2] http://sourceforge.net/tracker/?func=detailaid=2914578group_id=56967atid=482468 https://sourceforge.net/tracker/?func=detailaid=2920265group_id=56967atid=482468 [2] [1]
Patch so R CMD INSTALL pkg works
Hi,
You may have already fixed this. But in case it's still a bug,
on 4.2 the command
$ sudo R CMD INSTALL pkg
doesn't work. It's simple to test, download some CRAN package
tar.gz and try to install it from the command line.
The enclosed patches fixed this for me. See the July 3, 2007
thread Problem Installing R packages in OpenBSD for someone
else with the same problem:
https://stat.ethz.ch/pipermail/r-help/2007-July/135577.html
Thanks,
Mark
-- begin rfix1.diff
To apply, type
$ cd /usr/local/bin
$ sudo patch -p0 this.diff
--- /dev/null Tue Jul 21 07:48:58 2009
+++ R Sat Aug 18 13:40:14 2007
@@ -8,11 +8,11 @@
fi
R_HOME=${R_HOME_DIR}
export R_HOME
-R_SHARE_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R/share
+R_SHARE_DIR=/usr/local/lib/R/share
export R_SHARE_DIR
-R_INCLUDE_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R/include
+R_INCLUDE_DIR=/usr/local/lib/R/include
export R_INCLUDE_DIR
-R_DOC_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R/doc
+R_DOC_DIR=/usr/local/lib/R/doc
export R_DOC_DIR
# Since this script can be called recursively, we allow R_ARCH to
-- end rfix1.diff
-- begin rfix2.diff
To apply:
$ cd /usr/local/lib/R/bin
$ sudo patch -p0 this.diff
--- /dev/null Tue Jul 21 07:57:10 2009
+++ R Tue Jul 21 08:00:41 2009
@@ -2,17 +2,18 @@
# Shell wrapper for R executable.
R_HOME_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R
+R_HOME_DIR=/usr/local/lib/R
if test -n ${R_HOME} \
test ${R_HOME} != ${R_HOME_DIR}; then
echo WARNING: ignoring environment value of R_HOME
fi
R_HOME=${R_HOME_DIR}
export R_HOME
-R_SHARE_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R/share
+R_SHARE_DIR=/usr/local/lib/R/share
export R_SHARE_DIR
-R_INCLUDE_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R/include
+R_INCLUDE_DIR=/usr/local/lib/R/include
export R_INCLUDE_DIR
-R_DOC_DIR=/usr/obj/i386/R-2.5.0p0/fake-i386/usr/local/lib/R/doc
+R_DOC_DIR=/usr/local/lib/R/doc
export R_DOC_DIR
# Since this script can be called recursively, we allow R_ARCH to
-- end rfix2.diff
lighttpd
I can see from the openbsd cvs logs that the openbsd port was updated to 1.4.18 (fixing a security issue) on Fri Oct 5 14:56:50 2007 UTC. The 4.2 lighttpd package is 1.4.16, so did the fix occur after the 4.2 freeze? Also, I didn't see any posts on ports-security for this issue. Is the gmane listing [1] incomplete, or do some issues not make it to ports-security? Thanks, m [1] http://news.gmane.org/group/gmane.os.openbsd.ports.security/last=/force_load=t
Re: lighttpd
On 12/3/07, Landry Breuil [EMAIL PROTECTED] wrote: It has already been discussed, there is no one available to handle security updates to -stable ports. Missed that, I was searching on lighttpd. I have now read Nikolay's message re: -stable. Too bad. :( It is recommended to use -current if you want maintained ports with security updates. I am at 4.2 now. If I upgrade to the Nov. 26th snapshot, I must rebuild all installed packages using the ports tree, correct? Must I rebuild all installed ports each time I update to a new snapshot or via cvs up? Thanks, m
