Re: Building OpenSSL 3.3.1 links with system libcrypto and libssl

[Jonathan Perkin <jperkin%mnx.io@localhost>]

* On 2024-09-30 at 15:18 BST, Mads Rasmussen wrote:

> I am going to hammer on this, until its resolved. I think the issues with the
> order of -L parameters and the presence of /usr/local/lib should be resolved,

Before this thread descends any further, it must be pointed out that 
just because the output may show /usr/local/lib it does not mean that 
the path is actually being used.

pkgsrc uses compiler wrappers to transform all input command 
lines and modify them based on a number of different parameters.  If you 
look at .work.log in the work directory you will see lines that start:

 [*] ...

followed by lines that start:

 <.> ...

The first one is the unmodified command line which probably matches the 
one that you are looking at in the output.  The second one is the 
transformed one that is actually being executed, and it will almost 
certainly not include /usr/local/lib.

You should also see that buildlink reordered paths so that the buildlink 
library directory comes first, and the symlinks inside that directory 
are configured to point to either the native or pkgsrc versions of each 
library dependency.

This is fundamental to how pkgsrc works to ensure that when you select a 
builtin or a pkgsrc version of something, it is actually used correctly 
and doesn't just happen by random.  If this _isn't_ working, then it's a 
serious bug.

One thing that can happen when you use a bootstrapped compiler from 
pkgsrc is that even with the wrappers in place, depending on how the 
compiler is configured it can still pull in things from places we've 
tried to tell it not to look.  You may want to start there, e.g. copy
pasting the <.> commands from the work log and adding -v and seeing what 
the search path ordering is.

--
Jonathan Perkin   -   mnx.io   -   pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com