On 13 Jun 2003, Rob Siemborski said:
> On Fri, 13 Jun 2003, Igor Brezac wrote:
>
>>> Anything that goes inside a lib should be -fPIC. Really. I have
>>> done this in the Debian build (which runs OK in S/390, IA64,
>>> Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes
>>> are in CM
On Fri, 13 Jun 2003, Lawrence Greenfield wrote:
>Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT)
>From: Rob Siemborski <[EMAIL PROTECTED]>
>
>> > Yep. Arch dislikes mixing PIC and non-PIC code inside a
>> > relocatable object.
>>
>> Correct. On Solaris, I build lib/ and perl/
On Fri, 13 Jun 2003, Rob Siemborski wrote:
> On Fri, 13 Jun 2003, Igor Brezac wrote:
>
> > > Anything that goes inside a lib should be -fPIC. Really. I have done this in
> > > the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...)
> > > ages ago. I don't know if these changes ar
Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT)
From: Rob Siemborski <[EMAIL PROTECTED]>
> > Yep. Arch dislikes mixing PIC and non-PIC code inside a
> > relocatable object.
>
> Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC
> just to build cyrus-imap perl stuff.
On Fri, 13 Jun 2003, Igor Brezac wrote:
> > Anything that goes inside a lib should be -fPIC. Really. I have done this in
> > the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...)
> > ages ago. I don't know if these changes are in CMU Cyrus.
>
> This in true only for shared libs
On Fri, 13 Jun 2003, Henrique de Moraes Holschuh wrote:
> On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote:
> > Compiling with the -fPIC fixes the problem. I had to do this for the
> > following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c
> > util.c libisieve.c prot.c
> >
> > Why
On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote:
> Compiling with the -fPIC fixes the problem. I had to do this for the
> following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c
> util.c libisieve.c prot.c
>
> Why does -fPIC fix this problem?
Because of either:
1. AMD64 is unfo
[EMAIL PROTECTED] wrote:
Compiling with the -fPIC fixes the problem. I had to do this for the
following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c
util.c libisieve.c prot.c
Why does -fPIC fix this problem?
Code to be used in a shared library must be position-independent, s
Compiling with the -fPIC fixes the problem. I had to do this for the
following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c
util.c libisieve.c prot.c
Why does -fPIC fix this problem?
> [EMAIL PROTECTED] wrote:
>
>>make[2]: Entering directory `/root/src/cyrus-imapd-2.1.13/perl/
[EMAIL PROTECTED] wrote:
make[2]: Entering directory `/root/src/cyrus-imapd-2.1.13/perl/imap'
rm -f blib/arch/auto/Cyrus/IMAP/IMAP.so
LD_RUN_PATH="/usr/lib64" cc -shared -L/usr/local/lib64 IMAP.o -o
blib/arch/auto/Cyrus/IMAP/IMAP.so ../../lib/libcyrus.a -lssl -lcrypto
/usr/lib64/gcc-lib/x86_64-
Unfortunately, you've snipped the part that would show what's really
broken: the compilation of libcyrus.a. It looks like Perl on that
system is misconfigured, and didn't compile libcyrus.a with the -fPIC
option needed to link it into a shared library.
[EMAIL PROTECTED] wrote:
I have a dual A
I have a dual AMD Opteron configured with the SUSE Linux 8 for AMD64.
I am testing the trail system out. The problem comes in when the make
gets to compiling the Perl IMAP module. Cyrus SASL compiled fine.
GCC: gcc version 3.2.2 (SuSE Linux)
Perl ver: 5.8.0
Cyrus SASL ver: 2.1.13
./configure --
12 matches
Mail list logo
