FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 10-11-2011, 08:13 AM
"Francesco P. Lovergine"
 
Default Bug#643894: netcdf.mod in libnetcdf-dev incompatible with default gfortran version in sid

On Fri, Sep 30, 2011 at 06:00:08PM +0200, Giacomo Mulas wrote:
> Package: libnetcdf-dev
> Version: 1:4.1.1-5
> Severity: important
>
> The libnetcdf-dev package in sid is way too old, it was generated several
> versions ago of the default gfortran compiler. As a result, the included
> netcdf.mod is of the wrong version, and the module cannot be included with
> the present day default gfortran. This can be fixed (and I did so locally)
> by a plain recompile of the package on a current sid system (working around
> some minor hassles). Please recompile and upload an up-to-date version.
>

While I can understand perfectly that a simple rebuild would fix the issue,
I guess some strict dependencies are simply missed in the netcdf source package,
because this kind of problem should not be raised at all (i.e. current gfortran
and libnetcdf-dev binaries should be not installable at all together).
Someone that knows gfortran compiler better than me could probably
point that problem.

--
Francesco P. Lovergine


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111011081343.GA2250@blegrez.ba.issia.cnr.it">htt p://lists.debian.org/20111011081343.GA2250@blegrez.ba.issia.cnr.it
 
Old 10-11-2011, 09:19 AM
Giacomo Mulas
 
Default Bug#643894: netcdf.mod in libnetcdf-dev incompatible with default gfortran version in sid

On Tue, 11 Oct 2011, Francesco P. Lovergine wrote:


While I can understand perfectly that a simple rebuild would fix the issue,
I guess some strict dependencies are simply missed in the netcdf source package,
because this kind of problem should not be raised at all (i.e. current gfortran
and libnetcdf-dev binaries should be not installable at all together).
Someone that knows gfortran compiler better than me could probably
point that problem.


It's not necessarily a gfortran only problem, it also happens if you use
other compilers (i.e. intel, pathscale etc.). Upon creating a .mod file the
compiler and abi version are recorded there, so that mixing object files
compiled with different abis (due to compiler or version) is not possible.

However, what you suggest is also not correct, because gfortran-4.4 is still
available in sid: the problem is just that it is not the default any more. So
it would be incorrect to "fix" the netcdf source file so that it is
uninstallable if you have a gfortran package > the number at which the
default was changed. Moreover, since the netcdf maintainer cannot know in
advance at which version number of the gfortran metapackage the default
gfortran will be changed, how can (s)he know what Conflict: to set?

IMHO, the least incorrect way of handling this should be that when the
default compiler gets changed, an important, or critical, or whatever bug
should be filed against all packages whose libraries and/or .mod files (in
the case of gfortran) are incompatible with the new default compiler
version, "waking up" the maintainer to recompile the package. In a very
large number of cases, since nothing more than recompiling would be needed,
this could be even done (or at least attempted) by NMUs.

By the way, again IMHO, it should be an important issue to guarantee, at all
times, that all libraries included in the distribution are consistent with
(which usually means "compiled with") the default compiler. For all users,
like me, who develop/maintain scientific (or other) software, this would
remove a great number of issues with e.g. codes segfaulting because some of
the libraries they use were compiled with a different compiler version (it
happens all the time, e.g. with lapack, atlas, blas, scalapack, blacs,
fftw3...). So it would be really desirable (for me) for the policy to

mandate that a change of the default compiler triggers a recompile of all
packages including binary libraries (via automatic bugs filed on them).

Just my 2. In any case, I solved my personal problem recompiling the
packages that needed recompiling for my needs, the bug report was meant to
help others so that they did not need to waste the same time I wasted to
track and solve the same problem...

Bye
Giacomo

--
__________________________________________________ _______________

Giacomo Mulas <gmulas@oa-cagliari.inaf.it>
__________________________________________________ _______________

OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222
Tel. (UNICA): +39 070 675 4916
__________________________________________________ _______________

"When the storms are raging around you, stay right where you are"
(Freddy Mercury)
__________________________________________________ _______________
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
 

Thread Tools




All times are GMT. The time now is 07:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org