Re: [Opengrads-devel] dynamic supplibs checking

[Arlindo da S. <da...@al...>]

Jennifer,

   It is a busy day for me, I haven't read the exchange in great
detail. A couple of comments,

1) The clean-up/refactoring is very welcome

2) Having a flexible build that would look for dependencies in the
supplibs and if not found look "around" sounds good in principle but
can be tricky to implement. The supplibs not only builds everything
statically, but do so cooperatively: dependencies are resolved within
the supplibs. Having the build look at the supplibs and them elsewhere
needs to be done with extreme care so that we don't ended up using 2
different versions of the external libraries.  For this reason I
always felt it was safer to either build with the supplibs exclusively
or else look around. The point is, we need to make sure that external
libraries being used are built consistently.

3) About the detection m4 macros. More and more packages are providing
tidbits of m4 macros to detect their library which we can incorporate
in our build. As much as it makes sense we should ntry to use these m4
fragments "as is" without much grads customization. This way we would
be able to upgrade it when I new version of the package are brought
in.

4) Regarding

--enable-dyn-supplibs    never look for "supplibs" and always use DYN
macros to look for libraries
--disable-dyn-supplibs    always use "supplibs" and never use DYN
macros to look for libraries

I never liked the term "dynamic supplibs".  It really means, look
around for the dependencies as any other package would do - those
libraries do not have to conform to any of the supplibs conventions.
I'd suggest
something like:

--with-supplibs[=SUPPLIBDIR]        which tries to resolve the
dependencies within the supplibs
--without-supplibs                               the opposite

Now, for those cases where the user would prefer to use the system
libraries and complement it with the supplibs for those few libraries
they don't have this could be done simply with specific macros such as

--with-netcdf=include_path,lib_path

or by simply setting the CPPFLAGS, etc. I'd not try do to this
automatically: it is tricky and prone to error.

Regarding the question of defaults. Building against pre-compiled
supplibs is the easiest and more likely to produce correct binaries.
I have had very good experience with v1.9.0-rc1 and v2.0.ax.oga.y
builds. So, --with-supplibs could be the default. However, if the
supplibs cannot be found you could issue an warning:

- Cannot find supplibs; either download them from http:/.... or
specify --without-supplibs for satisfying the dependencies with
locally installed libraries.

5) Readline. One of the portabilities issues I ran into recently is
termcap/ncurses. Termcap is deprecated and recently I have added
ncurses to the supplibs, although as of yet not all pre-compiled
supplib tarballs have ncurses in them.

6) Labeling the binaries. The opengrads builds have consistently used
the config.guess script to determine the the architecture labeling of
the tarballs, while COLA has been using Linux distro specific
labeling. My experience is that the i686-pc-linux binaries have been
extremely portable, with the x86_64 slightly less so. Even when the
x86_64 did not quite work, rebuilding against the pre-compiled x86_64
supplibs did the trick. And in most cases the i686 built works on
x86_64, so many users just went with that. It took some
experimentation, and excluding the openssl/termcap libraries is one of
the fine tunings I had to do.

  Just my 2 cents.

       Arlindo



On Fri, Aug 1, 2008 at 9:59 AM, Jennifer Adams <jm...@co...> wrote:
>
> On Aug 1, 2008, at 8:55 AM, Patrice Dumas wrote:
>
>> On Fri, Aug 01, 2008 at 08:09:12AM -0400, Jennifer Adams wrote:
>>> Dear Experts,
>>>
>>> I've been pecking away at the configure scripts and thinking about
>>> the
>>> logic in them. There's a lot of cruft in there -- support of
>>> "historical" stuff that is no longer relevant, and outdated platform
>>> dependencies.
>>
>> Do you see that in configure.in/acinclude.m4 from, for example,
>> grads-2.0.a2, or in the macros used with --enable-dyn-supplibs in
>> opengrads?
> The cruft I'm talking about is anything related to the CRAY, support
> for the "wi" command, directory names called "supplibs-sol55", stuff
> like that.
>
>> I don't see that in configure.in/acinclude.m4. It is
>> present in opengrads, but it is not an issue, in my opinion. On the
>> contrary, it allows to build grads against old libdods, for example,
>> which is possible and should not be dropped in my opinion.
> I don't want GrADS 2.0 to keep trying to support libraries that
> depend on old versions of other libraries and compilers. My remedy
> for GrADS's bad case of versionitis is to forget the past and make it
> work with current versions of the dependent libraries. For example, I
> need to make sure I've got HDF4 built with the --disable-netcdf
> option, and that option is working properly in HDF4.2r3 (this version
> has finally eliminated all dependence on netcdf.h  -- oh, If I had a
> dollar for every pain that netcdf.h has caused me ... I'd get a free
> lunch!) The whole DODS mess is the worst offender. libgadods, libdap+
> +, libnc-dods, RIP.  Can't wait till libnc-dap.a is swept up into
> libnetcdf.a.
>
>> Also those
>> macros in fact come from other sources and should be kept synchronized
>> with these sources (mostly opendap).
> The dyn-supplibs macros are the ones I want to bring into the GrADS
> mainstream, to be used by default.
>
>>
>>> It seems to me that the default behavior should be to look
>>> for a directory called "supplibs" (in ./ and ../) and if not found
>>> then
>>> go hunting in the system for the required libraries, creating a
>>> dynamically linked executable. To create a more portable build, the
>>
>> Does this means that --enable-dyn-supplibs is the default unless a
>> ./supplib or ../supplib directory exists, and if a ./supplib or ../
>> supplib
>> directory exists one has to add --enable-dyn-supplibs to link against
>> system libraries? It it is what you meant, this seems reasonnable
>> to me.
>
> I want ./supplibs to be the first place to look for libraries, then
> if they don't exist there, go hunting for them in the system. If a
> user knows where a library is, but it's not in ./supplibs, then the --
> with configure flag is used to guide the hunting.
>
>>
>>> configure flag "--disable-shared" will stick with what's in the
>>> "supplibs"  directory and use the "-L/ga_supplb_path/libname.a"
>>> syntax
>>> instead of -L/path -lname" .
>>
>> That is not clear to me. What would the difference be between a build
>> with "--disable-shared" and a build with a ./supplib or ../supplib
>> directory present would be?
>
> You're right, there would be no difference if "supplibs"  always
> trumps the system location. I guess the --enable-dyn-supplibs flag
> could disable the check for ./supplibs or ../subblibs and then system
> location would trump "supplibs".
>
>>
>>> The "--with-PACKAGE" configure options will
>>> be used to guide the hunting for a specific library, something like
>>> --with-hdf=/opt/local (and then it will look for
>>> /opt/local/lib/libmfhdf.a and /opt/local/include/mfhdf.h)
>>
>> Agreed. It could even be used to use some supplibs but not all.
>> --without-* could still be used to disable a feature.
>
> Yes, the --without flag could save configuration time if you don't
> care about enabling a certain feature. The HDF group has a nice model
> for configuration with dependent libraries. I am going to borrow some
> stuff from them and separate out each library that is required. I'll
> look for libz.a, if not found, I can skip looking for a lot of other
> libraries (png, gd, hdf, grib2). If I do find it, add it to my list
> of libs and includes and continue, enabling features as I go through
> the list of libraries.
>
>
>> I don't understand clearly, however, if you want to use the same
>> macros
>> to detect the system libraries and the supplib libraries. If it is the
>> case it won't be that easy to achieve, because linking staticaly
>> against a supplib means supplying the path of the static
>> library or enclose the static link in -Wl,-static -lname -Wl,-dy (for
>> gcc, at least). This wouldn't easily be done with the system library
>> detection macros.
> Hmm.  Let's consider the readline case. Current code is :
>
>   if test "$ga_dyn_supplibs" = "yes" ; then
>     GA_LIB_READLINE([use_readline=yes readline_libs=""])
>   else
>     GA_CHECK_READLINE([use_readline=yes])
>   fi
>
> What if I changed that to something like:
>
>   if test "$ga_dyn_supplibs" = "yes" ; then
>     GA_DYN_READLINE([use_readline=yes readline_libs=""])
>   else
>     GA_SUPPLIBS_READLINE([use_readline=yes],[use_readline=no])
>     if teset "$use_readline" = "no" ; then
>       GA_DYN_READLINE([use_readline=yes readline_libs=""])
>     fi
>   fi
>
> Where GA_SUPPLIBS_READLINE only looks in ./supplibs and always uses
> the static link -L/supplibs/libname.a
>
> Would that produce the desired result?
>
> Jennifer
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>



-- 
Arlindo da Silva
da...@al...