Re: [Pan-users] Re: Are gmime and pcre required during runtime?

[Phil]

Thanks Duncan.  Yes, it's Linux, a Knoppix variant.

So what's happening is that gmime and pcre, which are
not on the system, won't make shared libraries when I
compile them, so there's no shared libs for pan to
find, so it compiles these in statically, yes. 
configure.log says ld doesn't do shared linking, and
it complains about g++ not supporting shared libs. I
tried using a slightly more recent version of gcc, no
change.

Which is ok, it works, though the pan binary is large,
and trying to strip it just gives a "file truncated"
error.

1. Do you happen to know if the pcre and gmime non-lib
executables that get compiled along with the pcre and
gmime static libs are used in some way by Pan, or can
I safely delete them?  I want to remove unneeded stuff
to reduce the size of the package I'll make from this.

2. Is the gmime uuencode and uudecode, which are 0.5MB
each, any better than say Busybox uuencode/uudecode?

Thanks for any help.


--- Duncan <address@hidden> wrote:

> Phil <address@hidden> posted
> address@hidden,
> excerpted below, on  Fri, 20
> Jul 2007 09:13:18 -0700:
> 
> > Ah, to answer my own question:  I see now that
> both pcre and gmime have
> > compiled statically.  So pan found ligmime-2.0a,
> libpcre.a etc to
> > statically link in.
> > 
> > These libs compile by default statically, or is
> there something they
> > didn't like about my system to make shared
> libraries?
> 
> You don't say so I'm assuming that LiveCD distro was
> Linux, not one of 
> the BSDs or some such.  Also, you seem to know some
> already as you were 
> able to discover the static linking on your own, so
> forgive me if this is 
> a bit basic.
> 
> On Linux, at least GNU/Linux (so using the GNU libc
> and linker, might be 
> different if a different userspace libc and etc are
> used), *.a libraries 
> are static, *.so* libraries are dynamic.  What was
> compiled in would 
> depend on what the linker found to compile in.  If
> it comes across the 
> static libraries first, it'll compile them in.  If
> it comes across the 
> dynamic libraries first, it'll use them.
> 
> It's quite possible the LiveCD you were using
> arranged things so the 
> static libraries were first in the compiler/linker
> search order, so you /
> wouldn't/ have problems running stuff you'd just
> compiled and saved, 
> after a reboot.
> 
> FWIW, here on Gentoo/amd64, naturally compiled from
> sources, such issues 
> come up from time to time, because dynamic libraries
> need compiled and 
> linked with -fPIC on AMD64 (x86_64, so the Intel
> version as well), while 
> static libraries don't as they are compiled directly
> into the apps.  If 
> the library build is trying to compile once and use
> the same object files 
> for both static and dynamic libraries, there's
> generally a problem, since 
> one needs -fPIC and the other doesn't.  Sometimes
> the problem can be 
> worked around by simply manually adding -fPIC to the
> CFLAGS/CXXFLAGS, 
> other times not.  Beyond that, I generally file a
> bug and let the Gentoo 
> amd64 arch devs handle it.
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." 
> Richard Stallman
> 
> 
> 
> _______________________________________________
> Pan-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/pan-users
> 



      
____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz