Hello,
On 27.06.2012 22:43, Carson Gaspar wrote:
On 6/27/2012 7:36 AM, Dilyan Palauzov wrote:
Moreover, does it make any difference, if imapd links with
libcyrus_sieve and libcyrus_sieve links with libcom_err, or if imapd
links explicitly with both libcyrus_sieve and libcom_err ?
What is
On Fri, Jun 29, 2012, at 02:20 AM, Florian Pflug wrote:
On Jun28, 2012, at 01:53 , Greg Banks wrote:
On Wed, Jun 27, 2012, at 04:36 PM, Dilyan Palauzov wrote:
Moreover, does it make any difference, if imapd links with
libcyrus_sieve and libcyrus_sieve links with libcom_err, or if imapd
On Wed, Jun 27, 2012, at 08:54 AM, Greg Banks wrote:
On Wed, Jun 27, 2012, at 12:27 AM, Bron Gondwana wrote:
/usr/bin/ld.bfd.real: /usr/lib/libcom_err.a(error_message.o): relocation
R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared
object; recompile with
On Wed, Jun 27, 2012, at 07:58 AM, Bron Gondwana wrote:
On Wed, Jun 27, 2012, at 08:54 AM, Greg Banks wrote:
On Wed, Jun 27, 2012, at 12:27 AM, Bron Gondwana wrote:
/usr/bin/ld.bfd.real: /usr/lib/libcom_err.a(error_message.o): relocation
R_X86_64_32 against
Hello,
as far as I understand, the systemwide libcom_err.a is non PIC, the
libcyrus_imap and libcyrus_sieve are PIC and it is not portable to
dymically link non-PIC libcom_err.a with PIC libcyrus_sieve . Yes, but
how to proceed in this case? Currently, Makefile.am states, that
libcyrus_imap
On 6/27/2012 7:36 AM, Dilyan Palauzov wrote:
Does somebody know if it is portable to link the PIC executable (e.g.
imapd) with PIC libcyrus_sieve, and with non-PIC libcyrus_imap ?
Yes, executables may be linked with PIC and non-PIC objects (otherwise
every executable would need to be
On Wed, Jun 27, 2012, at 04:36 PM, Dilyan Palauzov wrote:
Hello,
as far as I understand, the systemwide libcom_err.a is non PIC, the
libcyrus_imap and libcyrus_sieve are PIC and it is not portable to
dymically link non-PIC libcom_err.a with PIC libcyrus_sieve . Yes, but
how to proceed
On Tue, Jun 5, 2012, at 12:49 PM, Дилян Палаузов wrote:
Hello,
now libcyrus and libcyrus_min are compiled once as shared libraries,
once under perl/ as non-static convenience libraries,
perl/imap/IMAP.so and perl/sieve/managesieve/managesieve.so link
statically with the non-static
On Wed, Jun 27, 2012, at 12:27 AM, Bron Gondwana wrote:
/usr/bin/ld.bfd.real: /usr/lib/libcom_err.a(error_message.o): relocation
R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared
object; recompile with -fPIC
/usr/lib/libcom_err.a: could not read symbols: Bad value
On Sun, Jun 10, 2012, at 08:28 PM, Carson Gaspar wrote:
On 6/10/12 7:32 PM, Greg Banks wrote:
On Sat, Jun 9, 2012, at 04:42 PM, Carson Gaspar wrote:
./configure
--prefix=/Tools/SunOS_5.11_i86pc_amd64/cyrus-imapd-2.5.autofoo
--sysconfdir=/etc
On 6/10/12 7:32 PM, Greg Banks wrote:
On Sat, Jun 9, 2012, at 04:42 PM, Carson Gaspar wrote:
./configure
--prefix=/Tools/SunOS_5.11_i86pc_amd64/cyrus-imapd-2.5.autofoo
--sysconfdir=/etc
--with-sasl=/Tools/SunOS_5.11_i86pc_amd64/cyrus-sasl-git-20120609
--with-cyrus-group=cyrus
On Sat, Jun 09, 2012 at 08:05:20AM +1000, Greg Banks wrote:
Excellent, I'm looking forward to hearing how that goes.
If anyone out there builds on MacOS or BSD, it would be great if you
could build the dev/libtool branch and report your experiences.
We should see if we can get some time on
On 6/8/12 2:22 PM, Carson Gaspar wrote:
If I have some time this weekend, I'll try building the dev/libtool
branch and provide more feedback, as I install every package into it's
own tree, so I will trigger any missing RPATH issues.
OK, so I just filed a bunch of bugs against cyrus-sasl and
[ Much perl tsuris elided ]
Folks keep talking about linking a static libfoo.a into a dynamic
libbar.so. This MUST NOT HAPPEN. Linking non-PIC code into a shared
object will fail in unpredictable ways. It may _appear_ to work, but it
really won't. The Solaris linker will usually scream bloody
Sent from my iPhone
On 09/06/2012, at 7:22, Carson Gaspar car...@taltos.org wrote:
[ Much perl tsuris elided ]
;)
Folks keep talking about linking a static libfoo.a into a dynamic
libbar.so. This MUST NOT HAPPEN. Linking non-PIC code into a shared
object will fail in unpredictable
On Tue, Jun 5, 2012, at 12:49 PM, Дилян Палаузов wrote:
Hello,
now libcyrus and libcyrus_min are compiled once as shared libraries,
once under perl/ as non-static convenience libraries,
perl/imap/IMAP.so and perl/sieve/managesieve/managesieve.so link
statically with the non-static
Sent from my iPhone
On 07/06/2012, at 23:24, Bron Gondwana br...@fastmail.fm wrote:
On Tue, Jun 5, 2012, at 12:49 PM, Дилян Палаузов wrote:
Hello,
now libcyrus and libcyrus_min are compiled once as shared libraries,
once under perl/ as non-static convenience libraries,
perl/imap/IMAP.so
On Mon, Jun 4, 2012, at 04:22 PM, Дилян Палаузов wrote:
Hello,
then I suggest to build both static and shared libraries, to link all
services and user programmes with the shared libraries, to link the
IMAP.so and manageiseve.so files with the static libraries, and resolve
by this way
Hello,
now libcyrus and libcyrus_min are compiled once as shared libraries,
once under perl/ as non-static convenience libraries,
perl/imap/IMAP.so and perl/sieve/managesieve/managesieve.so link
statically with the non-static convenience libraries,
so that IMAP.so and managesieve.so do
On Tue, Jun 5, 2012, at 12:49 PM, Дилян Палаузов wrote:
Hello,
now libcyrus and libcyrus_min are compiled once as shared libraries,
once under perl/ as non-static convenience libraries,
perl/imap/IMAP.so and perl/sieve/managesieve/managesieve.so link
statically with the non-static
On Tue, Jun 5, 2012, at 12:49 PM, Дилян Палаузов wrote:
Hello,
now libcyrus and libcyrus_min are compiled once as shared libraries,
once under perl/ as non-static convenience libraries,
perl/imap/IMAP.so and perl/sieve/managesieve/managesieve.so link
statically with the non-static
Hello,
then I suggest to build both static and shared libraries, to link all
services and user programmes with the shared libraries, to link the
IMAP.so and manageiseve.so files with the static libraries, and resolve
by this way the need to insert RPATH in IMAP.so and managesieve.so .
I
Hello,
concerning the rpath for the perl shared objects IMAP.so and
managesieve.so, after all I found that MakeMaker uses as linker by
default the value returned by $Config(ld) (visible by running perl -V
under Linker and Libraries), which is sometimes ld='cc' and sometimes
ld='ld'.
If I
Sent from my iPhone
On 03/06/2012, at 20:50, Дилян Палаузов
dilyan.palau...@aegee.org wrote:
Hello,
concerning the rpath for the perl shared objects IMAP.so and
managesieve.so, after all I found that MakeMaker uses as linker by
default the value returned by $Config(ld) (visible by
On Fri, Jun 1, 2012, at 11:15 AM, Jeroen van Meeuwen (Kolab Systems)
wrote:
On 2012-05-31 18:25, Дилян Палаузов wrote:
- make install DISTDIR= causes warnings from libtool, that state,
that the libraries are not installed on the place they are intended
to
be installed (as configured)
Hello,
to sum up the issues with Libtool:
- the perl shared objects IMAP.so and managesieve.so do not contain
Library rpath on Greg's computer, but have it on mine. I have not
checked the details, but I think on my computer -rpath comes from the
fact, that to build LDFLAGS the file
On Thu, May 31, 2012, at 06:25 PM, Дилян Палаузов wrote:
Hello,
to sum up the issues with Libtool:
- the perl shared objects IMAP.so and managesieve.so do not contain
Library rpath on Greg's computer, but have it on mine. I have not
checked the details, but I think on my computer
On Fri, Jun 01, 2012 at 09:05:17AM +1000, Greg Banks wrote:
is considered by the dynamic loader, and are in ldconfig's path. So
what is the problem, when the perl shared objects do not contain -rpath?
I think the other executables shall also not contain it.
So this problem might not
28 matches
Mail list logo
