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
On 2012-05-29 1:25, Greg Banks wrote:
On Mon, May 28, 2012, at 09:33 PM, Dilyan Palauzov wrote:
[...]probably using make install DESTDIR= with
libtool is either wrong or implemented/handled wrong in
Automake/libtool.
Well, that sucks.
Why do not you use ./configure --prefix=$(DESTDIR),
Hello,
- Message from Greg Banks g...@fastmail.fm -
Date: Fri, 25 May 2012 13:17:05 +1000
From: Greg Banks g...@fastmail.fm
Subject: Re: Libtool and Support for Shared Libraries (2)
To: Дилян Палаузов dilyan.palau...@aegee.org,
cyrus-devel@lists.andrew.cmu.edu
On Mon, May 28, 2012, at 09:33 PM, Dilyan Palauzov wrote:
On my system managesieve.so and IMAP.so contain Library rpath.
Curious. Presumably it's a bug in my libtool or automake.
I'm tempted to put in a post-install check for Linux build hosts.
[...]probably using make install DESTDIR=
On Tue, May 22, 2012, at 01:47 PM, Дилян Палаузов wrote:
Hello,
commit Makefile.am: move the defintion of COM_ERR_LIB here
I don't think there's any point having COM_ERR_LIB and COM_ERR_LIBS,
just one should do, but we can tweak that later.
libimap and libsieve have to depend on
On Thu, May 17, 2012, at 01:21 AM, Дилян Палаузов wrote:
Hello,
I have integrated the comments about libtool/shared libraries and at the
end the changes are:
-- in libcyrus_min:libconfig:config_read one parameter is added for
config_need_data, so that this variable does not have to
Hello,
commit Makefile.am: move the defintion of COM_ERR_LIB here
I don't think there's any point having COM_ERR_LIB and COM_ERR_LIBS,
just one should do, but we can tweak that later.
libimap and libsieve have to depend on libcom_err.a whenever the bundled
libcom_err.a is used, so that the
Hello,
I have integrated the comments about libtool/shared libraries and at the
end the changes are:
-- in libcyrus_min:libconfig:config_read one parameter is added for
config_need_data, so that this variable does not have to be global and
presented in programs, not using config_read,
Hello,
Also, I notice that libcom_err.la is 'noinst'. How do you expect that cyrus
executable will be able to find this code at runtime on a platform which has
shared libraries but no system com_err library?
When the compilation of the internal com_err is requested, the files
from
Hello,
I put the libraries initially under $cyrus_prefix/lib (/usr/cyrus/lib),
because the directory $cyrus_prefix already existed.
If the intention is to move the files from $cyrus_prefix / $servicepath
(/usr/cyrus/bin), to /usr/libexec and /usr/bin, then the shared
libraries can be
On Fri, May 11, 2012 at 01:52:31PM +1000, Greg Banks wrote:
- Cyrus has multiple definitions of fatal(), with three different sets
of parameters. Apart from the basic sillyness of this arrangement,
it's just *asking* for unnecessary drama once you add shared libraries
into the mix. At
On Thu, May 10, 2012, at 01:04 AM, Дилян Палаузов wrote:
Hello,
I wanted to upload a new branch for testing libtool/shared libraries
functionality, but something went wrong and the 13 commits were uploaded
on top of 'master' instead of creating a separate branch. I am sorry
for the
Hello,
While we're at it, I'd love to split things like 'mailbox.c' which are
really libraries into a separate directory from 'imapd.c' which is a
system daemon only run by master from cyrus.conf and separate again
from cyr_dbtool.c which is a tool designed to be mainly run by humans.
I would
On Thu, May 10, 2012 at 04:03:26PM +0200, Дилян Палаузов wrote:
Hello,
While we're at it, I'd love to split things like 'mailbox.c' which are
really libraries into a separate directory from 'imapd.c' which is a
system daemon only run by master from cyrus.conf and separate again
from
On 2012-05-10 17:32, Bron Gondwana wrote:
On Thu, May 10, 2012 at 04:03:26PM +0200, Дилян Палаузов wrote:
Hello,
While we're at it, I'd love to split things like 'mailbox.c' which
are
really libraries into a separate directory from 'imapd.c' which is
a
system daemon only run by master from
On Thu, May 10, 2012, at 09:42 PM, Jeroen van Meeuwen (Kolab Systems)
wrote:
I agree. This tidying up is going to majorly invasive - don't forget we
want to merge in caldav before this happens as well.
I strongly recommend any major really tidying things up is postponed to
2.6.
Agreed.
Hello,
I wanted to upload a new branch for testing libtool/shared libraries
functionality, but something went wrong and the 13 commits were uploaded
on top of 'master' instead of creating a separate branch. I am sorry
for the surprises this might cause. Anyway...
I have updated
44 matches
Mail list logo
