tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: and mysterious build errors

> On Sun 23 Oct 2022 at 16:34:03 +0200, Havard Eidnes wrote:
>> At this point there are at least two ways forwards that i can
>> see:
>> 1) It's an operator error to let old libraries lay around
>>    (or perhaps specifically*), and I should just remove
>>    those and proceed with life.
> It has been my policy for a while (just because of incompatible changes
> in the C++ libraries) that if I have to compile one package with a newer
> gcc, I delete all packages and recompile them with the same gcc. I
> usually rebuild my chroot environment for this occasion to make sure it
> is clean.

Well, yes...  However, that's possibly what one can do on an
individual basis, possibly by manipulating /etc/mk.conf midway
(after the new gcc is installed).  I'm not sure we can translate
that properly into "what should pkgsrc do for a bulk build".

I can of course do as indicated above and remove
version 6, 7 and 8 from /usr/lib, remove any binary packages
which lists any of those's as REQUIRED (yes, there
were some), and re-start the entire bulk build.

I am however not entirely convinced that will sort out this
problem properly either.  The reason is that e.g. in the main R
package, ${PREFIX}/lib/R/library/grDevices/libs/ gets
installed, and via a dynamic dependency via,, and then, the
latter has a dynamic dependency which is found in
/usr/lib, since is most probably built with the
in-tree c++ compiler.

Once I've removed /usr/lib/, whenever the R module
mentioned earlier is loaded, you can end up with two different major
versions of dynamically loaded due to the divergent major
shared library version numbering scheme between pkgsrc gcc and in-tree
gcc.  That sounds to me like a recipe for disaster, but what do I know
-- is some trick used so that this isn't really a problem?  Or will
symbols now without warning or error resolve to just one of them?  Or
will you get a dynamic linker error message when the latter is
attempted loaded?

I guess I will find out.

>> 2) Find a way to put the library directory of gcc (in this case
>>    /usr/pkg/gcc10/lib) earlier in the RPATH.  This should preferably
>>    be done in a robust and "pkgsrc-ish" way.
> Many years ago I used a FreeBSD system where I had 2 different gcc
> versions installed. They had the same library names, but they were not
> compatible. Of course, one of them was first in the system-wide search
> path. So, programs compiled with the other version were suddenly
> mysteriously broken.  It cost me some time to find out what was going
> on.
> This event has brought me to crusade against library search paths.
> System-wide (like in FreeBSD or Linux) they are clearly no good. But
> per-executable (like we have with NetBSD's --rpath) is also not good
> enough. It can still cause the wrong version of a library to be used.
> ELF actually supports storing full paths to shared libraries, but our
> tools strip the path if it is given. I did some experiments with
> creating executables with full dependency paths, and with some tricks
> this is already possible. It would however be nicer if the tools didn't
> work against us here.

Indeed.  But I can see problems arising from such a scheme as well, in
that you then either can't easily execute built binaries from inside
the build tree, or forcing externally-maintained packages (what we
have with pkgsrc) to have to implement a "re-link" step before
installation to avoid having installed binaries pointing into the
build directory.

But what do I know, I've not tried following that path myself.


- Håvard

Home | Main Index | Thread Index | Old Index