making the png compat library more accessible

On Wed, May 17, 2006 at 04:33:55PM -0700, John Bowler wrote:
> From: Thomas Klausner
> >Currently, png-1.2.10 installs a compatibility
library with all
> >deprecated symbols, but removes any way to access
it except by
> >putting the complete path to the library on the
link line.
> 
> That wasn't the intention.  The compatibility library
is just
> the same (identical) library installed with a different
name -
> libpng.so instead of libpng12.so.  It's an
accident/error that
> the non-exported symbols are still in there.

I meant something different.
The install target installs the libpng.la library (with
all old symbols) and then manually overwrites the .la, .a,
and .so files with links to the libpng12 versions.
That still leaves libpng.so.3.9.0 (exact name depending
on the platform) as the library with the old symbols, but
there is no easy way to link against it.

My question was, since the library is still installed, why
not make it possible to use it by installing its own working
.la file?
Or stop installing it and just install the links, for the
programs
that do not use pkg-config or libtool and directly link
against
-lpng.

I hope I expressed myself clearer this time.

Cheers,
 Thomas


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement

Try again, here's a more direct answer:

From: Thomas Klausner
>The install target installs the libpng.la library (with
>all old symbols) and then manually overwrites the .la,
.a,
>and .so files with links to the libpng12 versions.

Partially correct.  The parenthetical comment '(with all
old symbols)' is incorrect.  libpng.* has the same symbols
and, indeed, the same implementation as libpng12.* - it is
built from the same object modules (only the link step
differs).

>That still leaves libpng.so.3.9.0 (exact name depending
>on the platform) as the library with the old symbols,
but
>there is no easy way to link against it.

Correct, that is the intention.  Nothing should be linked
against this library - nothing should be linked against
'libpng.so.3' ever.

>My question was, since the library is still installed,
why
>not make it possible to use it by installing its own
working
>.la file? 

Because that would result in some applications linked
against
libpng12.so.0 and some against libpng.so.3, since the two
libraries are identical this would be a pointless and
wasteful
duplication of identical code on the system.

>Or stop installing it and just install the links, for
the 
>programs that do not use pkg-config or libtool and
directly
>link against -lpng.

Because not installing it would result in applications
linked
against libpng.so.3 continuing to use the *previous* (minor)
version of that library, rather than being upgraded to the
latest version.

E.g. suppose a linux system has libpng 1.2.5, this will
have:

libpng12.so -> libpng12.so.0 -> libpng12.so.0.1.2.5
libpng.so -> libpng.so.3 -> libpng.so.3.1.2.5

Presumably there will be a mixture of applications, some
will
have a DLL entry for libpng12.so.0 some will record
libpng.so.3

Now suppose the system administrator upgrades to 1.2.9,
after
the upgrade:

libpng12.so -> libpng12.so.0 -> libpng12.so.0.9.0
libpng.so -> libpng12.so
libpng.so.3 -> libpng.so.3.9.0

So all the applications will have been upgraded (because on
linux
the dynamic linker cache will record 'libpng.so.3.9.0' as
the
library to use for libpng.so.3 - the symlink is, IIRC,
irrelevant).

If libpng.so.3.9.0 had not been installed, however, the
applications
which recorded a requirement for libpng.so.3 would still be
loading
libpng.so.3.1.2.5 - they would not have been upgraded.

When any application is relinked (i.e. linked, not
dynamically
linked) the application will now change to using
libpng12.so.0.
Gradually all applications on the system will change to use
the
correct (new) library name.

I hope that clarifies things - I tried to answer the exact
questions you asked this time.  If by 'old symbols' you
meant
the symbols which exported by libpng.so.3 but not exported
by
libpng12.so.0 on some platforms that's an error -
libpng.so.3
should not be exporting those symbols.  Still, it is a
harmless
error since it is impossible to link against libpng.so.3

John Bowler <jbowleracm.org>



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
png-mng-implement mailing list
png-mng-implementlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/png-m
ng-implement