Statically linking against bundled libagg

View: New views
4 Messages — Rating Filter:   Alert me  

Statically linking against bundled libagg

by jmdh :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The upstream for my package mapnik builds against an embedded copy of
agg, basically an unmodified agg 2.4. I am aware that this is an
undesirable situation and would like to try and fix this.

As far as I can tell from upstream, the decision to bundle AGG is only a
convenience for building on systems which don't have agg available
already.

Building and rudimentary testing against the agg 2.5 shipped with
unstable works, however I have a couple of concerns which make me
reluctant to change the build:

When building against system agg, I get the lintian error:

E: libmapnik0.5: shlib-with-non-pic-code usr/lib/libmapnik.so.0.5.0

this does not occur when compiling mapnik's own agg library.
I'm not sure what's happening here; does it indicate a mistake in the
way the agg library was built to start with or the way I'm building
mapnik?

The other concern is basically about the possibility of introducing
regressions in functionality by changing the build at this late stage.
This is entirely my own fault; I have left this issue unresolved for too
long.

So, questions:

1) can anyone offer advice about how to correct the above lintian error?
2) assuming I can fix the problem and upload a fix, should I ask for it
   to enter testing -- ie is it better to fix the embedded code copy
   issue for lenny or minimise the possibility of regressions?

For reference I attach the patch against the version of mapnik in
unstable I am using to build against the system agg library.

Thanks,
Dominic.

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


Index: debian/control
===================================================================
--- debian/control (revision 1047)
+++ debian/control (working copy)
@@ -1,7 +1,7 @@
 Source: mapnik
 Priority: optional
 Maintainer: Dominic Hargreaves <dom@...>
-Build-Depends: libboost-thread-dev (>= 1.34.0), libboost-filesystem-dev (>= 1.34.0), libboost-regex-dev (>= 1.34.0), libboost-program-options-dev (>= 1.34.0), libboost-python-dev (>= 1.34.1-9), libpng12-dev, libjpeg62-dev, libtiff4-dev, zlib1g-dev, libfreetype6-dev, libpq-dev, proj, libltdl3-dev, libfribidi-dev, python, debhelper (>= 5.0.38), python2.5-dev, python-central (>= 0.5.6), libgdal1-dev, libxml2-dev, libagg-dev, libboost-iostreams-dev (>= 1.34.0)
+Build-Depends: libboost-thread-dev (>= 1.34.0), libboost-filesystem-dev (>= 1.34.0), libboost-regex-dev (>= 1.34.0), libboost-program-options-dev (>= 1.34.0), libboost-python-dev (>= 1.34.1-9), libpng12-dev, libjpeg62-dev, libtiff4-dev, zlib1g-dev, libfreetype6-dev, libpq-dev, proj, libltdl3-dev, libfribidi-dev, python, debhelper (>= 5.0.38), python2.5-dev, python-central (>= 0.5.6), libgdal1-dev, libxml2-dev, libagg-dev, libboost-iostreams-dev (>= 1.34.0), libagg-dev
 Standards-Version: 3.7.3
 Section: libs
 XS-Python-Version: 2.5
Index: debian/changelog
===================================================================
--- debian/changelog (revision 1047)
+++ debian/changelog (working copy)
@@ -1,3 +1,9 @@
+mapnik (0.5.1-3~test.1) unstable; urgency=low
+
+  * Link against system agg library
+
+ -- Dominic Hargreaves <dom@...>  Sun,  6 Jul 2008 18:21:06 +0100
+
 mapnik (0.5.1-2) unstable; urgency=low
 
   * Update mapnik-utils extended description to fix formatting problem
Index: src/SConscript
===================================================================
--- src/SConscript (revision 1047)
+++ src/SConscript (working copy)
@@ -30,7 +30,7 @@
 prefix = env['PREFIX']
 install_prefix = env['DESTDIR'] + '/' + prefix
 
-libraries = ['agg'] + env['LIBS']
+libraries = env['LIBS']
 # Debian hack to clean up linking of main library (fixes dpkg-shlibdeps
 # warnings)
 libraries.remove('z')
Index: SConstruct
===================================================================
--- SConstruct (revision 1047)
+++ SConstruct (working copy)
@@ -94,7 +94,7 @@
     if not val in env[key]: env[key].append(val)
 
 # Libraries and headers dependency checks
-env['CPPPATH'] = ['#agg/include', '#include', '#']
+env['CPPPATH'] = ['/usr/include/agg2', '#include', '#']
 env['LIBPATH'] = ['#agg', '#src']
 
 # Solaris & Sun Studio settings (the `SUNCC` flag will only be
@@ -204,7 +204,7 @@
 #### Build instructions & settings ####
 
 # Build agg first, doesn't need anything special
-SConscript('agg/SConscript')
+#SConscript('agg/SConscript')
 
 # Build the core library
 SConscript('src/SConscript')


Re: Statically linking against bundled libagg

by Rene Engelhard :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Dominic Hargreaves wrote:
> When building against system agg, I get the lintian error:
>
> E: libmapnik0.5: shlib-with-non-pic-code usr/lib/libmapnik.so.0.5.0
>
> this does not occur when compiling mapnik's own agg library.
> I'm not sure what's happening here; does it indicate a mistake in the
> way the agg library was built to start with or the way I'm building
> mapnik?

You want -fPIC, both for your lib and agg. Try -lagg_pic if it exists
(when I maintained agg I created it - OOo once used agg too and still
has agg 2.4 in the code - unused by distros, though)

> The other concern is basically about the possibility of introducing
> regressions in functionality by changing the build at this late stage.
> This is entirely my own fault; I have left this issue unresolved for too
> long.

I can't (and won't) judge that as I don't know mapnik.

Regards,

Rene


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: Statically linking against bundled libagg

by Russ Allbery-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Dominic Hargreaves <dom@...> writes:

> Building and rudimentary testing against the agg 2.5 shipped with
> unstable works, however I have a couple of concerns which make me
> reluctant to change the build:
>
> When building against system agg, I get the lintian error:
>
> E: libmapnik0.5: shlib-with-non-pic-code usr/lib/libmapnik.so.0.5.0
>
> this does not occur when compiling mapnik's own agg library.  I'm not
> sure what's happening here; does it indicate a mistake in the way the
> agg library was built to start with or the way I'm building mapnik?

It looks like libagg is only available as a static library and not as a
shared library?  If so, to link it into a shared library, it must be built
position-independent (-fPIC) on almost every platform except i386.  This
error message, if libagg isn't PIC on any architecture, will likely result
in FTBFS on many architectures, such as amd64.

Ideally, libagg should provide a shared library.  Otherwise, any package
that links against the existing library would require a rebuild for any
security vulnerabilities in the library.

Policy 10.2 covers this somewhat.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: Statically linking against bundled libagg

by jmdh :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, Aug 04, 2008 at 01:42:47AM +0200, Rene Engelhard wrote:

> You want -fPIC, both for your lib and agg. Try -lagg_pic if it exists
> (when I maintained agg I created it - OOo once used agg too and still
> has agg 2.4 in the code - unused by distros, though)

Ah, that's the clue that I needed to answer my main point. Thanks!

On Sun, Aug 03, 2008 at 04:46:55PM -0700, Russ Allbery wrote:

> It looks like libagg is only available as a static library and not as a
> shared library?  If so, to link it into a shared library, it must be built
> position-independent (-fPIC) on almost every platform except i386.  This
> error message, if libagg isn't PIC on any architecture, will likely result
> in FTBFS on many architectures, such as amd64.
>
> Ideally, libagg should provide a shared library.  Otherwise, any package
> that links against the existing library would require a rebuild for any
> security vulnerabilities in the library.
>
> Policy 10.2 covers this somewhat.

There seems to be some discussion of why no shared library is built in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377270

Cheers,
Dominic.

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...