tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: scanner problem with packages depending on devel/gobject-introspection
Brook Milligan <brook%nmsu.edu@localhost> writes:
>> On Aug 1, 2018, at 8:10 AM, <maya%netbsd.org@localhost> <maya%netbsd.org@localhost> wrote:
>>
>> Are you using a symlink'd /usr/pkg or similar, some glib2 tool follows
>> symlinks to get the absolute path and pkgsrc masks most of the
>> filesystem in compiler command line flags
>
> Yes, ${PREFIX} refers to a symlink. I have now changed that to an absolute path and packages seem to be building fine.
>
> Would it make sense for bootstrap.sh or some part of mk/* to issue a
> warning about this requirement? It seems easy to miss, because many
> packages can be built just fine with the symlink. In my case I had
> several hundred packages already built successfully before running
> across the few that were confused by the symlink. This made me think
> that the problem was something related to those particular packages,
> not something systemic about the pkgsrc setup.
Yes. In my view we need to eiher
1) decide that it's a bug that packages lose when there is a symlink and
fix them or
2) change mk/ to fail hard with a message if there is a symlink issue
In the gobject-introspection case, what I've run into is not PREFIX
being a link, but having something like
/n0/ANONCVS/pkgsrc
as the pkgsrc checkout with a link from /usr/pkgsrc, and building from
/usr/pkgsrc/category/foo.
At the very least it would be nice to have a BROKEN_IF_SRC_SYMLINK
variable for such pesky packages, and have the build fail for them, even
if not for others.
Home |
Main Index |
Thread Index |
Old Index