Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 2010-Aug-31 17:14:50 -0400, jhell wrote: >On 08/31/2010 15:06, b. f. wrote: >> Would you elaborate, please? Where is a transcript showing the linking >> failure? >> Would you mail it to me off-list? > >Simply -lgfortran by it self should not work. Since lib directories Actually, IMO, since libgfortran.so is a support library for gfortran (much like libgcc_s.so is), it is reasonable for a user to expect that '-lgfortran' _is_ sufficient and the current behaviour is a bug. ports/129518 says I'm not the only person who think that. >-L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for >it to be found. And '-R/usr/local/lib/gcc44' as well. Note that a work-around has been added to bsd.gcc.mk so that ports with USE_GCC shouldbehave correctly and the problem is limited to using a non-base gcc outside the ports system. -- Peter Jeremy pgpPCGMr47ZD4.pgp Description: PGP signature
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On Wed, Sep 1, 2010 at 1:31 AM, Scot Hetzel wrote:
>> No, it will still take effect, after the math/blas Makefile is parsed,
>> unless _WITHOUT_SRCCONF is defined. See bsd.own.mk.
>>
>> b.
>>
>
> I created PR 150174, before I got your reply:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=150174
>
> I changed the port to use the OPTIONS framework to enable/disable
> profiled libraries. The only thing I didn't take into account was the
> bsd.lib.mk was still pulling in /etc/src.conf. To fix this we just
> need to add _WITHOUT_SRCCONF to the MAKE_ARGS (should they be
> MAKE_ENV?).
>
I retested using MAKE_ENV and it works. Unfortunately, adding
_WITHOUT_SRCCONF causes:
===> Building for blas-1.0_5
"/usr/share/mk/bsd.lib.mk", line 31: Malformed conditional
(${MK_ASSERT_DEBUG} == "no")
"/usr/share/mk/bsd.lib.mk", line 34: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 20: Malformed conditional
(${MK_BIND_LIBS} != "no")
:
due to _WITHOUT_SRCCONF is preventing bsd.own.mk from defining these variables.
I found a way to solve this, by defining SRCCONF="", which prevents
/etc/src.conf from being pulled in automatically.
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On Tue, Aug 31, 2010 at 11:58 PM, b. f. wrote: > On 9/1/10, Scot Hetzel wrote: >> On Tue, Aug 31, 2010 at 10:06 PM, b. f. wrote: >>> On 8/31/10, jhell wrote: > >>So according to bsd.own.mk, this is the correct test for the math/blas >>port to determine if profiling libraries should be built: >> >>.if !defined(WITHOUT_PROFILE) >>PLIST_FILES+= lib/libblas_p.a >>.endif > > No, you are leaving the order out of account. Apart from local and > custom makefiles, the makefiles are included so: > > /usr/share/mk/sys.mk > /etc/make.conf > /usr/share/mk/bsd.compat.mk > usr/share/mk/bsd.cpu.mk > Makefile(for math/blas) > /usr/share/mk/bsd.port.mk > /usr/share/mk/bsd.own.mk > /usr/ports/Mk/bsd.port.mk > /usr/ports/Mk/bsd.commands.mk > /usr/ports/Mk/bsd.perl.mk > /usr/ports/Mk/bsd.gcc.mk > /usr/ports/Mk/bsd.perl.mk > /usr/ports/Mk/bsd.licenses.mk > /usr/ports/Mk/bsd.sites.mk > ... > > So if NO_PROFILE or NOPROFILE is defined, a test for WITHOUT_PROFILE > in Makefile will still fail because NO_PROFILE is not mapped to > WITHOUT_PROFILE until bsd.own.mk, after the test. Just be patient and > we'll sort it out. > >> >> As can be seen, NOPROFILE is deprecated. > > It may be deprecated, but it will still take effect without > BURN_BRIDGES, and so still must be accounted for. > >> >> NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead >> of /etc/src.conf) to disable building profiled libraries in the >> FreeBSD sources and the math/blas port. > > No, it will still take effect, after the math/blas Makefile is parsed, > unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. > > b. > I created PR 150174, before I got your reply: http://www.freebsd.org/cgi/query-pr.cgi?pr=150174 I changed the port to use the OPTIONS framework to enable/disable profiled libraries. The only thing I didn't take into account was the bsd.lib.mk was still pulling in /etc/src.conf. To fix this we just need to add _WITHOUT_SRCCONF to the MAKE_ARGS (should they be MAKE_ENV?). Scot ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 01:41, b. f. wrote: > On 9/1/10, jhell wrote: >> On 09/01/2010 01:14, jhell wrote: >>> On 09/01/2010 00:58, b. f. wrote: No, it will still take effect, after the math/blas Makefile is parsed, unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. >>> >>> ports(7) pulls in src.conf ??? I hope I am not understanding this right... >>> >> >> No wonder why some of my ports are fricking ticking my counters with >> ccache! (!...@#!%#$%#@!$...@# !...@#!$@#...@% @$...@$@%...@#^) >> >> Now that I know I can burn that bridge right now by adding that to >> make.conf in a .if (.CURDIR:M/usr/ports*) > > Well, that would be wise in any event, to minimize build pollution. > But if you look in /usr/share/mk/bsd.port.mk, you will see that > bsd.own.mk is typically only included after _WITHOUT_SRCCONF is > defined. It is only exceptional cases where src.conf can have any > effect in Ports. > > b. So really then the only ultimate way to get around this if someone needed it that bad would be make.conf with a .CURDIR:M for /usr/src/* and pull in their own dynamically evil hidden defines. Or creating their own define that will not be referenced by anything in source or ports. This is mind boggling in more ways than one but at least knowing this now can save the heart ache in the future. Personally I think were hitting a design bump in the road here that raises concern of how is this going to look 5,10,15 years from now. This seems a pretty apparent warning sign IMHO that something should be forked from this now and work be done to separate the two and make a simple strategic set of knobs that are well defined and minimal by design ultimately easing the project and the cruft floating around the pkg_install-NG debates. I know these are a lot of things to handle all at once given the large amount there is to work with but since these all of a sudden have been coming out of the framework and becoming more and more apparent its time to fix them permanently. If only I had the time and the money to sit here all day I would be more than happy to take this on but unfortunately I don't, at least for right now. Thanks, Regards & Good Dreams, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 9/1/10, jhell wrote: > On 09/01/2010 01:14, jhell wrote: >> On 09/01/2010 00:58, b. f. wrote: >>> No, it will still take effect, after the math/blas Makefile is parsed, >>> unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. >> >> ports(7) pulls in src.conf ??? I hope I am not understanding this right... >> > > No wonder why some of my ports are fricking ticking my counters with > ccache! (!...@#!%#$%#@!$...@# !...@#!$@#...@% @$...@$@%...@#^) > > Now that I know I can burn that bridge right now by adding that to > make.conf in a .if (.CURDIR:M/usr/ports*) Well, that would be wise in any event, to minimize build pollution. But if you look in /usr/share/mk/bsd.port.mk, you will see that bsd.own.mk is typically only included after _WITHOUT_SRCCONF is defined. It is only exceptional cases where src.conf can have any effect in Ports. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 9/1/10, jhell wrote: > On 09/01/2010 00:58, b. f. wrote: >> No, it will still take effect, after the math/blas Makefile is parsed, >> unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. > > ports(7) pulls in src.conf ??? I hope I am not understanding this right... > In this case, yes. Because math/blas is one of a few ports that takes advantage of some base system makefiles to construct binaries and libraries. It's an old port (the software was written in the 70's and it was introduced to Ports in Oct. 1994, just a few months after the Ports repository was created), and since the needed machinery had just been constructed in the base system (this was back in the days when Fortran was still in the base system, and HPC was one of the key applications), they just used that machinery, rather than reinventing the wheel. But that means that, since it uses base system makefiles, it has inevitably been subject to some of the conventions and constructs of the base system (the latest change being the userland dtrace project, which has injected a lot of ctf stuff into the makefiles in -CURRENT), as well as those of Ports. That's not altogether bad (they influence one another, as jhell's problem with an absence of profiling libraries reminds us), but it has to be handled properly. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 01:14, jhell wrote: > On 09/01/2010 00:58, b. f. wrote: >> No, it will still take effect, after the math/blas Makefile is parsed, >> unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. > > ports(7) pulls in src.conf ??? I hope I am not understanding this right... > No wonder why some of my ports are fricking ticking my counters with ccache! (!...@#!%#$%#@!$...@# !...@#!$@#...@% @$...@$@%...@#^) Now that I know I can burn that bridge right now by adding that to make.conf in a .if (.CURDIR:M/usr/ports*) FF Sakes. Thank you. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 00:58, b. f. wrote: > No, it will still take effect, after the math/blas Makefile is parsed, > unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. ports(7) pulls in src.conf ??? I hope I am not understanding this right... -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 9/1/10, Scot Hetzel wrote: > On Tue, Aug 31, 2010 at 10:06 PM, b. f. wrote: >> On 8/31/10, jhell wrote: >So according to bsd.own.mk, this is the correct test for the math/blas >port to determine if profiling libraries should be built: > >.if !defined(WITHOUT_PROFILE) >PLIST_FILES+= lib/libblas_p.a >.endif No, you are leaving the order out of account. Apart from local and custom makefiles, the makefiles are included so: /usr/share/mk/sys.mk /etc/make.conf /usr/share/mk/bsd.compat.mk usr/share/mk/bsd.cpu.mk Makefile(for math/blas) /usr/share/mk/bsd.port.mk /usr/share/mk/bsd.own.mk /usr/ports/Mk/bsd.port.mk /usr/ports/Mk/bsd.commands.mk /usr/ports/Mk/bsd.perl.mk /usr/ports/Mk/bsd.gcc.mk /usr/ports/Mk/bsd.perl.mk /usr/ports/Mk/bsd.licenses.mk /usr/ports/Mk/bsd.sites.mk ... So if NO_PROFILE or NOPROFILE is defined, a test for WITHOUT_PROFILE in Makefile will still fail because NO_PROFILE is not mapped to WITHOUT_PROFILE until bsd.own.mk, after the test. Just be patient and we'll sort it out. > > As can be seen, NOPROFILE is deprecated. It may be deprecated, but it will still take effect without BURN_BRIDGES, and so still must be accounted for. > > NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead > of /etc/src.conf) to disable building profiled libraries in the > FreeBSD sources and the math/blas port. No, it will still take effect, after the math/blas Makefile is parsed, unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 00:10, Scot Hetzel wrote: > On Tue, Aug 31, 2010 at 10:06 PM, b. f. wrote: >> On 8/31/10, jhell wrote: >>> Looking closer at the math/blas & math/lapack ports: >>> >>> This statement does not make any sense. The logic is backwards for every >>> instance. And WITH_PROFILE would do. >>> .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) >>> PLIST_FILES+= lib/libblas_p.a >>> .endif >>> >>> Which is basically saying: >>> Add that profile lib if NOPROFILE is not defined "_p is a profiled lib >>> why would you want to install this if the admin has NOT defined NOPROFILE? >>> >> >> Er, I'm not sure what you're getting at here. No means no. Really. >> The default, as I explained, is to build and install the profiling >> libraries, unless one or more of three disabling variables has been >> defined. And that's the default because users of these ports often use >> the profiled libraries when analyzing performance of their programs, >> which are usually computationally-intensive. Why the three variables? >> Because they control whether the profiling libraries are actually >> built via bsd.compat.mk and bsd.lib.mk. >> > Actually there are only 2 *_PROFILE variables (WITH_PROFILE and > WITHOUT_PROFILE) that are user visible for the FreeBSD sources. The > NOPROFILE variable is depreceiated, and the NO_PROFILE variable is > only supposed to be used in Makefiles according to bsd.own.mk: > > # Define MK_* variables (which are either "yes" or "no") for users > # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the > # make(1) environment. > # These should be tested with `== "no"' or `!= "no"' in makefiles. > # The NO_* variables should only be set by makefiles. > > So according to bsd.own.mk, this is the correct test for the math/blas > port to determine if profiling libraries should be built: > > .if !defined(WITHOUT_PROFILE) > PLIST_FILES+= lib/libblas_p.a > .endif > > I also tested how these variables responded: > > vbox# cd /usr/src/lib/libcam > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE > > yes > > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE WITH_PROFILE=yes > yes > yes > > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE NO_PROFILE=yes > > no > yes > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE WITHOUT_PROFILE=yes > > no > > yes > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE NOPROFILE=yes > "/usr/share/mk/bsd.compat.mk", line 35: warning: NOPROFILE is > deprecated in favour of NO_PROFILE > > no > yes > > > As can be seen, NOPROFILE is deprecated. > > NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead > of /etc/src.conf) to disable building profiled libraries in the > FreeBSD sources and the math/blas port. > > Scot Thank you Scot As for src.conf Yes I know it would need to be defined in make.conf globally to effect src & ports. But to my belief at the time I did not believe that anything in ports would blindly assume that setting something with profiling would be acceptable which is why I suggested the if defined(WITH_PROFILE) instead. Things that enable options like profiling usually used for debugging that is not used in general usually lead to an infestation of other targets and programs that link against them and in some cases like the -PIE instance a while back with samba and cups where something in one of the source files was configured in a way that lead to global profiling of anything that had enabled -PIE during their builds resulting in *.gprof files being created in /. This is just one of the reasons why I don't like profiling enabled without the user knowing that its going to happen. For reference PR/143924 & MFC commit r205567 that happened during releng/7.2 days. Regards & Thank you again. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On Tue, Aug 31, 2010 at 10:06 PM, b. f. wrote: > On 8/31/10, jhell wrote: >> Looking closer at the math/blas & math/lapack ports: >> >> This statement does not make any sense. The logic is backwards for every >> instance. And WITH_PROFILE would do. >> .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) >> PLIST_FILES+= lib/libblas_p.a >> .endif >> >> Which is basically saying: >> Add that profile lib if NOPROFILE is not defined "_p is a profiled lib >> why would you want to install this if the admin has NOT defined NOPROFILE? >> > > Er, I'm not sure what you're getting at here. No means no. Really. > The default, as I explained, is to build and install the profiling > libraries, unless one or more of three disabling variables has been > defined. And that's the default because users of these ports often use > the profiled libraries when analyzing performance of their programs, > which are usually computationally-intensive. Why the three variables? > Because they control whether the profiling libraries are actually > built via bsd.compat.mk and bsd.lib.mk. > Actually there are only 2 *_PROFILE variables (WITH_PROFILE and WITHOUT_PROFILE) that are user visible for the FreeBSD sources. The NOPROFILE variable is depreceiated, and the NO_PROFILE variable is only supposed to be used in Makefiles according to bsd.own.mk: # Define MK_* variables (which are either "yes" or "no") for users # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the # make(1) environment. # These should be tested with `== "no"' or `!= "no"' in makefiles. # The NO_* variables should only be set by makefiles. So according to bsd.own.mk, this is the correct test for the math/blas port to determine if profiling libraries should be built: .if !defined(WITHOUT_PROFILE) PLIST_FILES+= lib/libblas_p.a .endif I also tested how these variables responded: vbox# cd /usr/src/lib/libcam vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE WITH_PROFILE=yes yes yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE NO_PROFILE=yes no yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE WITHOUT_PROFILE=yes no yes vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE NOPROFILE=yes "/usr/share/mk/bsd.compat.mk", line 35: warning: NOPROFILE is deprecated in favour of NO_PROFILE no yes As can be seen, NOPROFILE is deprecated. NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead of /etc/src.conf) to disable building profiled libraries in the FreeBSD sources and the math/blas port. Scot ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
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_ m
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 8/31/10, jhell wrote: > Looking closer at the math/blas & math/lapack ports: > > This statement does not make any sense. The logic is backwards for every > instance. And WITH_PROFILE would do. > .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) > PLIST_FILES+= lib/libblas_p.a > .endif > > Which is basically saying: > Add that profile lib if NOPROFILE is not defined "_p is a profiled lib > why would you want to install this if the admin has NOT defined NOPROFILE? > Er, I'm not sure what you're getting at here. No means no. Really. The default, as I explained, is to build and install the profiling libraries, unless one or more of three disabling variables has been defined. And that's the default because users of these ports often use the profiled libraries when analyzing performance of their programs, which are usually computationally-intensive. Why the three variables? Because they control whether the profiling libraries are actually built via bsd.compat.mk and bsd.lib.mk. > > Simple following would do. > .if (defined(WITH_PROFILE) > PLIST_FILES+= lib/libblas_p.a > ,endif > > Then if it is really a concern that this has to default to on, then use > the options framework to present that to the user. At least in this > instance the user will at least know whats going on. As I wrote earlier, there needs to be some additional logic here, at least warnings about NO*, and maybe some other steps. There is a confluence of base system options with port options here. I will discuss it with the maintainer. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 8/31/10, jhell wrote: > On 08/31/2010 15:06, b. f. wrote: >> Would you elaborate, please? Where is a transcript showing the linking >> failure? >> Would you mail it to me off-list? > > Simply -lgfortran by it self should not work. Since lib directories > gcc44 gcc45 gcc46 and such are not in the standard path > -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for > it to be found. > > Off list should not be necessary. ? 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. > With my change in objdump the only thing listed in objdump -x that is > relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no > undefined symbols. 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. > Would it be possible with this to check for the existence of -lc_p > before and opt out automatically while warning the user that the > profiled libc was not found so profiling will be unavailable. ? 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. 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. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
Looking closer at the math/blas & math/lapack ports: This statement does not make any sense. The logic is backwards for every instance. And WITH_PROFILE would do. .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) PLIST_FILES+= lib/libblas_p.a .endif Which is basically saying: Add that profile lib if NOPROFILE is not defined "_p is a profiled lib why would you want to install this if the admin has NOT defined NOPROFILE? Second add that lib if NO_PROFILE is defined ? see previous question still doing the wrong thing here. Third add that lib if WITHOUT_PROFILE is defined ? see previous two question still not doing the right thing here. Simple following would do. .if (defined(WITH_PROFILE) PLIST_FILES+= lib/libblas_p.a ,endif Then if it is really a concern that this has to default to on, then use the options framework to present that to the user. At least in this instance the user will at least know whats going on. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 08/31/2010 15:06, b. f. wrote: > Would you elaborate, please? Where is a transcript showing the linking > failure? > Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories gcc44 gcc45 gcc46 and such are not in the standard path -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. Off list should not be necessary. > > I don't find this to be the case. Perhaps you could provide listings for > `ldd -a /usr/local/lib/libblas.so.2`, `objdump -x > /usr/local/lib/libblas.so.2`, and > `make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and > without your change, off-list? > With my change in objdump the only thing listed in objdump -x that is relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no undefined symbols. Without my change it simply will not build unless I either a) remove -lgfortran or b) add -L/usr/local/lib/gcc44 > ? USE_FORTRAN=yes ==> USE_GCC=4.4 > > You don't see any relevant undefined symbols in the blas libraries? > > With regards to your statements about math/lapack and profiling: it > has been the case for some time that this port has built and installed > these libraries by default, perhaps because this port has mainly been > used by people concerned about numerical linear algebra and concrete > measures of performance. I recently added the statement you quoted to > allow users to avoid these libraries -- it intentionally mirrors the > similar statement in the allied port math/blas, where the form is is > dictated by the use of bsd.lib.mk to build the libraries. Given the > typical use of these ports, I don't think it is unreasonable to enable > profiling libraries by default. But if you don't like it, you can now > easily opt out. Would it be possible with this to check for the existence of -lc_p before and opt out automatically while warning the user that the profiled libc was not found so profiling will be unavailable. ? Specifically this port is making a blind assumptions that profiled libraries are installed on the system it is being installed on, I do not find that to be correct. Something like this would best be handled by options that default off. gfortran44 -O -pg -c dsecndtst.f -o dsecndtst.o gfortran44 -O -pg -c tstiee.f -o tstiee.o gfortran44 -O -pg -c ilaver.f -o ilaver.o gfortran44 -O -pg -c LAPACK_version.f -o LAPACK_version.o gfortran44 -Wl,-rpath=/usr/local/lib/gcc44 -pg -o testlsame lsame.o lsametst.o /usr/local/bin/ld: cannot find -lc_p collect2: ld returned 1 exit status *** Error code 1 -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
>The subject listed port fails to link during an upgrade from the >previous version. Looking into this further libblas.so.2 without being Would you elaborate, please? Where is a transcript showing the linking failure? Would you mail it to me off-list? >linked to gfortran is correct as in the already installed previous >version installed inspected with ldd(1) shows the same linking as the >new version without the -lgfortran linker flags. > I don't find this to be the case. Perhaps you could provide listings for `ldd -a /usr/local/lib/libblas.so.2`, `objdump -x /usr/local/lib/libblas.so.2`, and `make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and without your change, off-list? >Attached is the patch that solves the linking problem. I do not see any >dependents listed for this port for any of the gcc* ports that can be >installed so therefore I have removed the -lgfortran from LDADD. ? USE_FORTRAN=yes ==> USE_GCC=4.4 You don't see any relevant undefined symbols in the blas libraries? With regards to your statements about math/lapack and profiling: it has been the case for some time that this port has built and installed these libraries by default, perhaps because this port has mainly been used by people concerned about numerical linear algebra and concrete measures of performance. I recently added the statement you quoted to allow users to avoid these libraries -- it intentionally mirrors the similar statement in the allied port math/blas, where the form is is dictated by the use of bsd.lib.mk to build the libraries. Given the typical use of these ports, I don't think it is unreasonable to enable profiling libraries by default. But if you don't like it, you can now easily opt out. Regards, b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 08/30/2010 19:41, jhell wrote: > > The subject listed port fails to link during an upgrade from the > previous version. Looking into this further libblas.so.2 without being > linked to gfortran is correct as in the already installed previous > version installed inspected with ldd(1) shows the same linking as the > new version without the -lgfortran linker flags. > > Attached is the patch that solves the linking problem. I do not see any > dependents listed for this port for any of the gcc* ports that can be > installed so therefore I have removed the -lgfortran from LDADD. > > $FreeBSD: ports/math/blas/Makefile,v 1.47 2010/08/30 07:26:27 bf Exp $ It also appears that recent changes in math/lapack make blind assumptions that the user wants to compile these with ???PROFILING??? why? .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) Would this not be better with if (defined(WITH_PROFILE)) ?? But then again this port also breaks so I guess I do not have to worry about blind assumptions here. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
