Re: glibc warnings

2007/11/28, Justin Karneges <[email protected]>:
> On Wednesday 28 November 2007 2:07 am, Isak Savo wrote:
> > 2007/11/28, Justin Karneges <[email protected]>:
> > > Hi,
> > >
> > > I'm trying to build all of our deps with apbuild (openssl, zlib, Qt4),
> > > and I've mostly succeeded.  I can makepackage a test application using
> > > QtCore and it succeeds without warnings.  However, when I use QtGui, then
> > > I'm given this:
> >
> > Do you really need to ship Qt? I think it is better to link
> > dynamically to QT and use whatever version the user already has on his
> > system. That way this problem will go away.
>
> As another wrote, not all systems have Qt 4.  I also specifically need Qt 4.2
> (interface version).  Of course it is better to use the system Qt if
> available.  Ideally my application would link dynamically to Qt, and then the
> autopackage would determine if Qt 4.2+ is already present.  If it isn't, then
> there'd be some internal qt.package file that gets installed.  However, I
> haven't figured out how to do that yet so I thought the easiest approach
> would be to do a static build.

'require' in [prepare] will do that for you. If you autopackage QT and
put it in your sealed package then autopackage will install it if
needed, and use the system version it otherwise.

Of course, it will add up the size of your package pretty much, so it
might be better to provide it on an URL download instead (a bit more
tweaking to do, but it's doable, 'require' will handle it fine.)

> > OpenSSL is bad to ship because it is a security library and if you
> > ship it, the user won't benefit from the system upgrades.
>
> And the same for OpenSSL.  Ideally dynamic, with a dynamic lib installed by
> autopackage as necessary.  Until I figure this out, static seems like a
> simple route.

ok.

> > > "WARNING: Symbols from glibc 2.3 (or newer) were found. Consider using
> > > apbuild to allow users of older distros to run this binary.  If you are
> > > statically linking any libraries, make sure they are compiled with
> > > apbuild too."
> >
> > As you mentioned, its probably the X11 libs. I'm not sure you want to
> > go through an X11 recompile though :-)
>
> I don't?  This seems to contradict the autopackage documentation, which talks
> about how apbuild is used to statically link X11 libs.

I was more thinking of the effort needed to compile X11, but maybe
that is easy now with xorg. I remembered when it was Xfree, it was
quite tricky to compile.

But yes, statically linking X11 is a solution when you're not sure the
target user has dynamic versions of the x libs installed.

By the way, does anyone know of the status on this issue? Is it still
sane to statically link x libs by default?

> > You might be able to force QT to dynamically link to X, by setting
> > APBUILD_NO_STATIC_X to 1. See http://autopackage.org/apbuild-apgcc.php
>
> It already links dynamically by default.  I forced static linkage with
> APBUILD_STATIC.  Either way, I get glibc warnings.

Ok. It could actually be that QT has a hard dependency on some new
glibc symbol. Do objdump -p on the ELF files to see which versions it
needs (printed at the end). You can also do 'objdump -T myprogram' to
see which functions it needs (grep for GLIBC_2).

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]