[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] USRP on NetBSD, partly/mostly working now
From: |
Greg Troxel |
Subject: |
Re: [Discuss-gnuradio] USRP on NetBSD, partly/mostly working now |
Date: |
19 Dec 2005 15:42:43 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
Eric Blossom <address@hidden> writes:
> On Fri, Dec 16, 2005 at 03:59:39PM -0500, Greg Troxel wrote:
>
> > 1) buildit assumes that everything is in /usr, or perhaps that
> > everything is in the compiler's default paths.
>
> Yes. ./configure --help says this:
>
> Some influential environment variables:
> CC C compiler command
> CFLAGS C compiler flags
> LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
> nonstandard directory <lib dir>
> CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
> headers in a nonstandard directory <include dir>
>
> Use these variables to override the choices made by `configure'
> or to help it to find libraries and programs with nonstandard
> names/locations.
Sure, and when I call configure by hand or scripts I do that. pkgsrc
sets these as well. My view of buildit was that it was supposed to
just work, which in means following local conventions. I'll probably
spiff it up a bit once copyright papers are in order.
> > This isn't true on NetBSD. I added
>
> > LDFLAGS="-R/usr/pkg/lib -L/usr/pkg/lib" CPPFLAGS="-I/usr/pkg/include"
>
> Don't you see this problem with everything that builds using stuff
> from /usr/pkg? How do other packages handle it?
Yes. pkgsrc passes -R as LDFLAGS, and the pkgconfig files for
packages are patched to have -R as well.
> BTW, what's the -R ldflag do? Path for shared library resolution?
Yes. On NetBSD, ELF ld.so looks in a list from LD_LIBRARY_PATH and
/etc/ld.so.conf (discouraged on security grounds), paths from the
executable in DT_RPATH sections (where -R ends up), and then the
default path which is /usr/lib. So for libraries that aren't in
/usr/lib -- which is everything not part of the base system -- one
has to -L/usr/foo/lib -R/usr/foo/lib to find them at both link and
run time.
> I don't know the rationale for installing in /usr/gnuradio. We don't
> install much in the top level, so I don't think it's namespace
> pollution.
In the NetBSD world, /usr is only for the base system (which is
defined as what is built from the src and xsrc cvs modules), and
/usr/pkg is for the package system, where each file is registered to a
package. So while GNU Radio doesn't put much, it's still bits that
don't belong if not built from pkgsrc.
> > 2) GNU make is required in some cases. We could fix the makefiles to
> > work with BSD make also, or far easier just make buildit switch on
> > platform to invoke GNU make (gmake on BSD, and surely present on
> > systems that have a hope of compiling the prereqs).
>
> There aren't intended to be any GNU make dependencies.
> If there are, please let me know where, and if possible suggest a fix,
> or better yet, a patch.
OK, I will see and report. But it's easier for me to just use GNU
make than fix it, so I might just use GNU make.
With respect to included Makefiles, perhaps I'll just submit a patch
to chmod +w the target files before writing them. This is still gross
(to write stuff that is in CVS) but it will work.
--
Greg Troxel <address@hidden>
- Re: [Discuss-gnuradio] savannah cvs restructured; checkout neeeds updating, (continued)