math/blas linking to gfortran with LDADD?= -lgfortran

[jhell]

On 08/31/2010 20:06, b. f. wrote:
> ? gfortran44 builds the object files, and gcc44 performs the linking
> for the shared library.  Their default search directories normally
> allow them to find libgfortran at compile- and link-time.  And
> afterwards, at run-time, the appropriate rpath is inscribed in the
> binary (see bsd.gcc.mk: this has been done for some time now),  if the
> system linker hints aren't sufficient.  So this does not seem to
> explain your problem, and that's why I asked for more complete
> information.  Since I don't want to spam the list with that volume of
> material, that's why I asked for it to be sent via private email.

My apologies I did not mean to infer that off-list mailing of those were
a problem I just did not see it as needed, technically because math/blas
will simply not build without a path to the gcc44 directory i.e
-L/usr/local/lib/gcc44.

Mailing you separately the contents what you asked for. Everything
except the build errors as those are your standard linking errors for
file not found. and can be reproduced by adding garbage to LDFLAGS i.e.
-lslkdfksjdhf

> 
> As I said before, I cannot account for this -- I really need to see
> the complete information I requested earlier.  Since gfortran44 is
> used to build the library components, there should be undefined
> symbols relating to libgfortran in all of the libraries, and the rpath
> should be present in both cases, if all you did was remove the
> explicit libgfortran from LDADD.  The only difference should be the
> presence or absence of a DT_NEEDED tag for libgfortran.
> 
> I'll look into this.  There is a dichotomy here:  when building from
> source, base system profiling libraries are built and installed by
> default.  The same may not be true if the user installs a binary
> distribution, using something like systinstall(8).  It should be
> possible to handle both cases.

Specifically I use WITHOUT_PROFILE in src.conf(5) to ensure that those
libraries do not exist on the system in question due to cases like this
one. If I had not put that in there then I probably would not have been
called to attention with this upgrade error and blindly would have had
profiled libraries installed. I do have the libraries on hand if I
should ever need profiling with the system libraries but I do not. I
install these in a separate location for ease of use on testbeds.

One example that I have of prevention in this case is the re-entrant
version of libc. I once had to recompile libc and somehow ended up in
the libc_r directory instead and after installing this lib manually for
some reason or another it was being found first by every program on the
system causing a slow down. Not knowing what caused that slowdown I
began recompiling ports which I might add was terribly slow and after
compiling 50 or so ports and having them then directly linked to libc_r
I found the root cause of the problem ``libc_r'' not thinking twice
about this I removed libc_r, crashed the system and had to SU in and
edit libmap.conf to temporarily fix the problem until I could get all
those ports recompiled again.

So in short. To make sure this does not happen again on a client system
re-entrant & profiling are disabled on a larger scale. The side effect
is I find ports that blindly link to profiled libraries. So far I can
only account for these two ports in ~1.5 years of use & that is about
the time that the above problem arose and I decided to tend to it.

> 
> On your subsequent question about the form of the statement: for
> math/lapack, yes, the statement could be changed to fit into the
> OPTIONS framework.  But, as I wrote before, I put it in that form to
> mimic the similar statements in math/blas.  The statements in
> math/blas must take into account the NO* variables,  and
> WITHOUT_PROFILE, because the presence of these variables in the build
> environment or an included makefile is what actually controls whether
> the profiling libraries are built, via the relevant base system
> makefiles in /usr/share/mk, regardless of WITH_PROFILE. I will look
> into using the OPTIONS framework -- in the base system makefiles,
> unlike in Ports, there is a sanity check on the simultaneous use of
> WITH_FOO and WITHOUT_FOO.  So there are some added safeguards, not
> normally available for Ports, that may make it possible to integrate
> this with OPTIONS.


Here I did not define anything:
pkg_delete -d blas-\*
pkg_delete: file '/usr/local/lib/libblas_p.a' doesn't exist
pkg_delete: couldn't entirely delete package (perhaps the packing list
is incorrectly specified?)

WITHOUT_PROFILE appears to work as it is supposed to by not adding that
_p.a.

Anyway I think Ive come to a better understanding of the issue that is
really at hand with this case. It seems to me and I praise you guys/gals
for being able to deal with it but there is simply to many knobs to
account for things that could be handled by fewer knobs.


The way I see it is WITH_ means use this and WITHOUT_ means do not use
and can be contorted with operators like (!) in either form that already
adds enough complexity to handle even the stickiest situations with
ports but on top of that you have NOPROFILE NO_PROFILE etc... etc... and
whatever else may be used to define (NO|DONT|DO|THAT|WITH|THESE) If this
is for sheer compatibility then why aren't the *.mk files handling this
instead of forcing it upon the maintainers. If you were to write a C
program in this sense then gawd! only knows what the consequences would
be so why are we doing it here?.


Please do not take offense to any of this as I am just trying to
understand why in a sea of Makefile's & define's.

Regards,

-- 

 jhell,v