Discussion of technical issues related to the NetBSD package system

Stoned Elipot | 1 Oct 2003 10:22

Re: weird problems on sparc with loading cyrus-imapd21 IMAP extension for cyradm perl script

On Tue, Sep 30, 2003 at 04:08:18PM -0400, Greg A. Woods wrote:
[SNIP]
> Has anyone seen anything like this before?

I have. On sparc64.
It is supposed to be solved by adding "perl -V:cccdlflags" while
linking perl modules.
Grep for PERL_CCCDLFLAGS in mail/cyrus-imapd*/patches/*.
I haven't compiled cyrus-imapd21 on sparc64 in a while but I will soon,
may be the latest updates of the pkg missed some more fixes like theses...

Cheers, Stoned.

headers

Greg A. Woods | 1 Oct 2003 22:10

Re: weird problems on sparc with loading cyrus-imapd21 IMAP extension for cyradm perl script

[ On Wednesday, October 1, 2003 at 10:22:24 (+0200), Stoned Elipot wrote: ]
> Subject: Re: weird problems on sparc with loading cyrus-imapd21 IMAP extension for cyradm perl script
>
> On Tue, Sep 30, 2003 at 04:08:18PM -0400, Greg A. Woods wrote:
> [SNIP]
> > Has anyone seen anything like this before?
> 
> I have. On sparc64.
> It is supposed to be solved by adding "perl -V:cccdlflags" while
> linking perl modules.
> Grep for PERL_CCCDLFLAGS in mail/cyrus-imapd*/patches/*.

Yes those changes are all still there.

As you no doubt know PERL_CCCDLFLAGS is just a really poor hack for
trying to ensure that whatever flags are needed to generate position
independent code are passed to the compiler when compiling any code to
be included in the dynamic loaded extension.

In this case the resulting setting after running ./configure is
PERL_CCCDLFLAGS"-DPIC -fPIC" and I can see those flags being used on
every compilation when building both the Cyrus IMAPD internal libraries
(used in IMAP.so) as well as the IMAP.o file itself.

Is there any easy way to tell for certain whether any given object file
was compiled with '-fPIC'?  Some files I've tested to not contain a
_GLOBAL_OFFSET_TABLE_ symbol even though they were compiled with
'-fPIC'.  The only indicator I've found that seems to be reliable so far
is that "objdump -r" will show undefined symbols from the .text section
as having type R_SPARC_WPLT30 when compiled with '-fPIC' and type

(Continue reading)

headers

Stoned Elipot | 2 Oct 2003 16:50

Re: weird problems on sparc with loading cyrus-imapd21 IMAP extension for cyradm perl script

On Wed, Oct 01, 2003 at 04:10:48PM -0400, Greg A. Woods wrote:
> If this could be the issue then the problem may be with my libsasl2
> libraries since at the moment I have only libsasl2.a.  However on i386
> where "cyradm" works I also have only the static-only libsasl2.a and it
> was most definitely not compiled with '-fPIC'.  Is '-fPIC' not
> universally necessary on i386 for all objects in loadable modules?

I believe so. Why don't you have a shared libsasl2.a? Is that on
purpose ?

headers

Greg A. Woods | 2 Oct 2003 21:17

Re: weird problems on sparc with loading cyrus-imapd21 IMAP extension for cyradm perl script

[ On Thursday, October 2, 2003 at 16:50:08 (+0200), Stoned Elipot wrote: ]
> Subject: Re: weird problems on sparc with loading cyrus-imapd21 IMAP extension for cyradm perl script
>
> On Wed, Oct 01, 2003 at 04:10:48PM -0400, Greg A. Woods wrote:
> > If this could be the issue then the problem may be with my libsasl2
> > libraries since at the moment I have only libsasl2.a.  However on i386
> > where "cyradm" works I also have only the static-only libsasl2.a and it
> > was most definitely not compiled with '-fPIC'.  Is '-fPIC' not
> > universally necessary on i386 for all objects in loadable modules?
> 
> I believe so.

Hmmm... then why does it work?  

And why does the dynamic loader on sparc produce such a content free
(and/or misleading) error message when it doesn't work?

> Why don't you have a shared libsasl2.a? Is that on
> purpose ?

As you may know I've got a hate-on for all things dynamic.  

Now of course I'm willing to bend to accomodate certain things where
dynamic loading is the easier approach, and perl interpreter extensions
are examples such places (besides Makefile.aperl support is currently
quite broken on NetBSD, at least for pkgsrc modules, not to mention that
cyradm itself would need a minor bit more hacking to use the custom perl
interpreter containing the IMAP extensions).

Normally though I would build a full compliment of static and shared

(Continue reading)