Initial: -------- I'm using a FreeBSD system which underwent an upgrade ('cvsup', 'makeworld', 'portupgrade', etc) just prior to the release of 5.3. I jumped the gun just a little, but things were pretty locked down for the release so I anticipate that most or all of these issues might be seen by those with the first 'stable' release of the FreeBSD 5.x line. On the other hand, I may not have done my upgrade perfectly so that could be a source of issues too. In any event, those with low bandwidth connections may well have machines with a similar history to mine and may run across the same set of problems... I tend to install a minimal system and build everything from ports (rather than pre-compiled packages.) Some port distributions require the use of auto(x) tools. In my opinion, this is as often as not a sign of ignorance on the part of the distro maintainers but be that as it may, it has resulted on multiple versions of the auto(x) tools on my system. Trashing and/or changing them has the potential to ruin my ability to upgrade ports using FreeBSD's ports infrastructure ('portupgrade' and friends) so I am reticent to do that. Life could be easier (or not!) if I were to choose a 'one true' version of the auto(x) tools, root around trashing and symlinking things, and call this a dedicated dev box for the foo project, but I don't wish to do that if it is aviodable. ------------ Remember: For ports with dialogs... (i.e., devel/boost, math/fftw3) make showconfig (to show last config options.) make rmconfig (to remove them and start over.) For more, see 'Default targets' in /usr/ports/Mk/bsd.port.mk Note that the config data is stored in /var/db/pkg (or some such) and is not very accessible. A head-scratcher for folks only moderately familiar with FreeBSD's ports system. The initial thought of excersizing make distclean succeeds in requiring a re-download of the source tarball but doesn't re-set the config dialog options! --------- Boost: Most ports build fine but devel/boost is broken. - setenv PYTHON_VERSION 2.3 (if using tcsh) This gets over the inability to find the right version of Python which _is_ 2.3 in a 5.3 current distro. - Bad macro in /usr/include/stddef.h. See bug: 72307 One (probably stupid) solution is to patch that header file. Another might be to build a port of gcc_3.4.2 and build with that (instead of the sytem compiler which is also 3.4.2), but it's not the route I choose. --------- Lotsa troubles related to FreeBSD not desiring to have a 'one true' auto{x} version on the system. Two possible solution occur to me imediatly, and I tried both in an effort to get over a problem which turned out to be unrelated (see below.): - ${AUTO(x)} instead of auto(x) - play with PATH Both can be set in a top level file and sourced by ./bootstrap... at least in my initial experiments which didn't include trying the ./for_all_dirs script. Note that the ugly details of the way the FreeBSD ports system works around this (and probably the next mentioned) problem can be seen in /usr/ports/Mk/bsd.autotools.mk. It's too confusing and kludgy for me to try to imediatly emulate for the purposes of this excersize! --------- Big problems with libtool. Symptoms are that configure bombs not being able to find './ltconfig'. The issue seems to be that both libtool13.m4 and libtool15.m4 exist in /usr/local/share/aclocal and they both contain a varient of the AC_PROG_LIBTOOL macro. Exactly how and why both m4 collections made it into that location is unclear pending further research, but whatever the case, aclocal seems to choose to integrate the 1.3 macro into ./aclocal.m4, and libtool 1.5 does not use or create a link for ./ltconfig. A viable solution is to but a copy of the desired libtool macro library into the ./config directory: thuppi@skink ~/src/gnuradio/co/gr-build/gnuradio-core/config> cp /usr/local/share/aclocal/libtool15.m4 . --------- Swig: FreeBSD ports version of swig miss by one the patchlevel needed for GnuRadio. Didn't want to install over the top of the 'system' one, so I built and installed it in a local dir: ~/src/swig_1.3.23/local_install Note the hassle of 'make install' breaking. Probably from useing 'make' instead of 'gmake'. Anyway, a method of fixing it lies in the one patch file from the ports dir (though it doesn't patch correctly due to a change in the Makefile.in.) That is, the addition of a '|| true' to several lines. A quick and dirty hack to use it is simply to add it to the front of PATH...later make a configure option to use it. setenv PATH /usr/home/thuppi/src/swig_1.3.23/local_install/bin:${PATH} ---------- Boost: The configure flag: --with-boost-include-dir=/usr/local/include/ _is_ required to make it through the configure process. ---------- More AutoX: Lots of problems associated with srd_1000_base in src/lib/swig. After a bunch of fooling around, I discovered that I needed to use a custom build of automake17 (not currently a valid port in the ports collection). In order to both build it, and to use it, I need to have access to autoconf, and the way I achieved this was to put it in my PATH. So: printenv PATH /usr/local/libexec/autoconf259:/usr/home/thuppi/src/swig_1.3.23/local_install/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/home/thuppi/bin At this time, I've managed to get a build -------- Since the time of the above, I discovered that automake17 was _not_ the problem. I was able to get a build of the src dist with automake19 iirc. Also, the last mentioned note did _not_ get me a clean build of HEAD. I'm writing this several weeks after my last attempts to build HEAD, and don't precisely remember the details, but I always got a build crash associated with missing references in...um...let me look...Here it is: gnuradio_swig_python.cc: In function `PyObject* _wrap_new_sdr_1000_base__SWIG_1(PyObject*, PyObject*)': gnuradio_swig_python.cc:51451: error: no matching function for call to `sdr_1000_base::sdr_1000_base()' ../../../src/lib/io/sdr_1000.h:38: note: candidates are: sdr_1000_base::sdr_1000_base(const sdr_1000_base&) ../../../src/lib/io/sdr_1000.h:44: note: sdr_1000_base::sdr_1000_base(int) gnuradio_swig_python.cc: At global scope: gnuradio_swig_python.cc:233: warning: 'swig_type_info* SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used gnuradio_swig_python.cc:346: warning: 'void SWIG_PropagateClientData(swig_type_info*)' defined but not used gnuradio_swig_python.cc:829: warning: 'void* SWIG_Python_MustGetPtr(PyObject*, swig_type_info*, int, int)' defined but not used gnuradio_swig_python.cc:843: warning: 'int SWIG_Python_ConvertPacked(PyObject*, void*, size_t, swig_type_info*, int)' defined but not used gmake[4]: *** [gnuradio_swig_python.lo] Error 1 gmake[4]: Leaving directory `/usr/home/thuppi/src/gnuradio/co/gr-build/gnuradio-core/src/lib/swig' At that point, I switched to working on other software to get my Ten-Tec RX-320D reciever to operate and decode junk on my FreeBSD box. I'll get back to this project eventually. Hopefully these notes will provide an interested viewer with some things of interest for the time being until I get back to this project and cleaning up the notes. - Tom (Mon Jan 3 18:13:41 PST 2005) -------------