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
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 cal
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
>> links explicitly with both libcyrus_sieve and libcom_er
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 pro
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 compiled
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 d
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 again
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; recom
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
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-stat
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
> >> --with-sasl=/Tools/Su
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 --with-cyrus-user
On Sat, Jun 9, 2012, at 04:42 PM, Carson Gaspar wrote:
> 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 iss
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 cyr
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 o
Sent from my iPhone
On 09/06/2012, at 7:22, Carson Gaspar 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 ways.
Understood
[ 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 07/06/2012, at 23:24, Bron Gondwana 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 and perl/sieve/man
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-stat
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-stat
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 need
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
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 gues
Sent from my iPhone
On 03/06/2012, at 20:50, Дилян Палаузов
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 running perl -
V under Link
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
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 con
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) and the executables are not going to
work
(as they will not be able to find the lib
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 mig
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 comput
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 libdb-4.8
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=$(DESTDI
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 DESTD
Hello,
- Message from Greg Banks -
Date: Fri, 25 May 2012 13:17:05 +1000
From: Greg Banks
Subject: Re: Libtool and Support for Shared Libraries (2)
To: Дилян Палаузов ,
cyrus-devel@lists.andrew.cmu.edu
On Tue, May 22, 2012, at 01:47 PM, Дилян Палаузов wrote
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
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
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 h
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, upda
On Tue, May 15, 2012, at 11:52 PM, Дилян Палаузов wrote:
> 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?
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 libcom_er
On Tue, May 15, 2012, at 11:24 PM, Дилян Палаузов wrote:
> Hello,
>
> >>> commit "convert com_err/et/libcom_err.a to a libtool archive"
> >>>
> >>> You should also fix the 2nd argument to db_panic() in
> >>> lib/cyrusdb_berkeley.c.
> I think renaming "errno" to "noerr" in lib/cyrus_berkeley.c:d
Hello,
commit "convert com_err/et/libcom_err.a to a libtool archive"
You should also fix the 2nd argument to db_panic() in lib/cyrusdb_berkeley.c.
I am not sure: gcc does not complain. I think it matters only when
errno is a global variable, in db_panic() it is local.
Many systems define o
On Mon, May 14, 2012, at 05:34 PM, Дилян Палаузов wrote:
> 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),
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 renamed
On 2012-05-11 2:00, Greg Banks wrote:
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 u
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 t
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.
Agre
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 fro
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
> >fro
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 01:04 AM, Дилян Палаузов wrote:
>-- libimap and libsieve are installed under pkglibdir =
> $cyrus_prefix/lib, e.g. /usr/cyrus/lib . If the libraries are moved to
> $libdir, then they shall probably be renamed to libcyrus_imap and
> libcyrus_sieve to avoid conflict
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,
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 cyrus-imapd
54 matches
Mail list logo
