Converting from .a to .so

Hi,

The future versions of anjuta look like they're going to
rely on using
netCDF which I have just about packaged. The problem is that
it uses
static libs rather than shared ones.

Is there a safe way in the spec file to convert between a
static and
shared lib so I can submit it (and feed back the need for
shared
upstream) or so I need to mess with the makefile?

TTFN

Paul
-- 
"Mmmmmmmm....Shakira geschmiert mit schokolade"
sagt Homer
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On 12/24/06, Paul <paulall-the-johnsons.co.uk>
wrote:
> Hi,
>
> The future versions of anjuta look like they're going
to rely on using
> netCDF which I have just about packaged.

Uhm... isnt netcdf already packaged?

owners.list shows:
Fedora Extras|netcdf|Libraries for the Unidata network
Common Data Form (NetCDF
v3)|edeh3.com|extras-qafedoraproject.org|

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

Hi,

> > The future versions of anjuta look like they're
going to rely on using
> > netCDF which I have just about packaged.
> 
> Uhm... isnt netcdf already packaged?
> 
> owners.list shows:
> Fedora Extras|netcdf|Libraries for the Unidata network
Common Data Form (NetCDF
> v3)|edeh3.com|extras-qafedoraproject.org|

D'oh!

Okay, for future reference, is there a way to do what I need
to do
(convert from .a to .so)?

TTFN

Paul
-- 
"Mmmmmmmm....Shakira geschmiert mit schokolade"
sagt Homer
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On 12/24/06, Paul <paulall-the-johnsons.co.uk>
wrote:
> Okay, for future reference, is there a way to do what I
need to do
> (convert from .a to .so)?

Don't you just need to pass -shared to the compiler?

Hmm... it looks like the current netcdf packages do NOT
created shared
libs. Hmmm... this maybe a problem that needs to be
resolved.

-jef

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On 12/24/06, Jeff Spaleta <jspaletagmail.com> wrote:
> On 12/24/06, Paul <paulall-the-johnsons.co.uk>
wrote:
> > Okay, for future reference, is there a way to do
what I need to do
> > (convert from .a to .so)?
>
> Don't you just need to pass -shared to the compiler?
>
> Hmm... it looks like the current netcdf packages do NOT
created shared
> libs. Hmmm... this maybe a problem that needs to be
resolved.


Also note that that libnc-dap exists in Extras as a shared
library.
libnc-dap claims to be a call for call replacement of the
netcdf
library.  I STRONGLY suggest that you look at linking
against
libnc-dap instead of the state netcdf implementation.

http://w
ww.opendap.org/download/nc-dods.html

-jef

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On Sun, 24 Dec 2006 14:52:29 -0900, Jeff Spaleta wrote:

> On 12/24/06, Paul wrote:
> > Okay, for future reference, is there a way to do
what I need to do
> > (convert from .a to .so)?
> 
> Don't you just need to pass -shared to the compiler?

The original question is wrong to begin with. Without a sane
versioning
scheme that is supported by the upstream developers,
creating any shared
library at the RPM package level adds no value. Quite the
opposite even,
when upstream prefers changing the library API often.
Packagers make up a
SONAME that works for a single release, but which breaks the
ABI as often
as upstream changes the library in a way that would require
an updated
library version plus a rebuild of dependencies.
Alternatively, over time
they end up with a series of SONAMEs which conflicts with
the official
library versioning scheme when upstream makes the step
towards publishing
shared libs.

> Hmm... it looks like the current netcdf packages do NOT
created shared
> libs. Hmmm... this maybe a problem that needs to be
resolved.

Hence the answer to the original post is: Talk to upstream!

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On Sun, Dec 24, 2006 at 11:26:36PM +0000, Paul wrote:
> Hi,
> 
> Is there a safe way in the spec file to convert between
a static and
> shared lib so I can submit it (and feed back the need
for shared
> upstream) or so I need to mess with the makefile?

Next netcdf release will certainly ship dynamic libraries.
In the mean 
time linking against the static netcdf libs should be the
way to go.

--
Pat

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On 12/24/06, Michael Schwendt <bugs.michaelgmx.net> wrote:
> Hence the answer to the original post is: Talk to
upstream!


upstream is currently working on version 4 of the netcdf
library which
will be merding hdf5 and netcdf together. The new library is
in alpha
and unfortunately is not stable enough for me to maintain
inside
fedora. I wish I could, I'd very much like to maintain and 
use the
python-netcdf4
module as part of fedora based work.

But my other suggestion stands libnc-dap  is designed to be
a call for
call replacement for the netcdf version 3. It might be much
more
beneficial to start linking all fedora space items against
libnc-dap
instead of netcdf.  I'm already working on building
ScientificPython
against libnc-dap as a test

-jef

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On Sun, Dec 24, 2006 at 03:01:42PM -0900, Jeff Spaleta
wrote:
> 
> Also note that that libnc-dap exists in Extras as a
shared library.
> libnc-dap claims to be a call for call replacement of
the netcdf
> library.  I STRONGLY suggest that you look at linking
against
> libnc-dap instead of the state netcdf implementation.
> 
> http://w
ww.opendap.org/download/nc-dods.html

libnc-dap indeed implements the netcdf api, but it also adds
support
for dods, it may not be right for anjuta, or it may be
better, depending on 
the netcdf use  (I really don't know why anjuta would need
netcdf, though). 
libnc-dap has a copy of the netcdf library in the code, so
it 
doesn't add much regarding security.

--
Pat

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On 12/24/06, Patrice Dumas <pertususfree.fr> wrote:
> libnc-dap has a copy of the netcdf library in the code,
so it
> doesn't add much regarding security.

If all the fedora space apps which need netcdf3 support use
the
libnc-dap implementation, then we reduce the issue to
exactly one
codebase... that shared library. If there was a security
issue, do we
even know how many things in the fedora space are building
against the
static libraries in netcdf-devel right now?  It's tough to
get a
handle on how many things are building with netcdf support
with the
available repoquery tool since there's no shared library
requires to
match against.  We'll have to dig through all the spec files
and look
for netcdf-devel.  That's not something I'm looking forward
to doing.

-jef

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On Mon, 25 Dec 2006 01:36:52 +0100 Patrice Dumas
<pertususfree.fr>
wrote:

> On Sun, Dec 24, 2006 at 11:26:36PM +0000, Paul wrote:
> > Hi,
> > 
> > Is there a safe way in the spec file to convert
between a static and
> > shared lib so I can submit it (and feed back the
need for shared
> > upstream) or so I need to mess with the makefile?
> 
> Next netcdf release will certainly ship dynamic
libraries. In the
> mean time linking against the static netcdf libs should
be the way to
> go.

Yes, and I'll update Extras to the new version shortly after
its out of
beta (in a month or two, supposedly).

Also, the current netCDF static libs shipped in Extras are
built with
-fPIC so you can use them to build other shared libs as is
done with
NCO.

Ed

-- 
Edward H. Hill III, PhD  |  edeh3.com  |  http://eh3.com/
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

On Sun, 24 Dec 2006 23:47:40 +0000 Paul <paulall-the-johnsons.co.uk>
wrote:

> Hi,
> 
> > > The future versions of anjuta look like
they're going to rely on
> > > using netCDF which I have just about
packaged.
> > 
> > Uhm... isnt netcdf already packaged?
> > 
> > owners.list shows:
> > Fedora Extras|netcdf|Libraries for the Unidata
network Common Data
> > Form (NetCDF v3)|edeh3.com|extras-qafedoraproject.org|
> 
> D'oh!
> 
> Okay, for future reference, is there a way to do what I
need to do
> (convert from .a to .so)?


Hi Paul,

If you look in the nco package you'll see how it builds
shared libs
using the netCDF static lib.  This works because I compiled
the netCDF
static lib with the necessary -fPIC flag.

And as others have pointed out the next version of netCDF
(supposedly
due in ~2 months) will have full shared libs support.

Ed

-- 
Edward H. Hill III, PhD  |  edeh3.com  |  http://eh3.com/
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

Paul <paulall-the-johnsons.co.uk> wrote:
> The future versions of anjuta look like they're going
to rely on using
> netCDF which I have just about packaged. The problem is
that it uses
> static libs rather than shared ones.

Too bad.

> Is there a safe way in the spec file to convert between
a static and
> shared lib so I can submit it (and feed back the need
for shared
> upstream) or so I need to mess with the makefile?

Nope.

A shared library /has/ to be position independent code (at
least if it is
to make some sense having it shared), a static library
normally isn't.
-- 
Dr. Horst H. von Brand                   User #22616
counter.li.org
Departamento de Informatica                    Fono: +56 32
2654431
Universidad Tecnica Federico Santa Maria             +56 32
2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32
2797513

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list

Array

Array