Hello Arkadiusz,
* Arkadiusz Miskiewicz wrote on Sat, Jun 14, 2008 at 12:18:25AM CEST:
> In recent libtool version lt_dlforeach function was dropped as part of
> deprecated API.
>
> What function is able to replace the same functionality, now?
lt_dlhandle_iterate is what comes closest. But it
Hello Mark,
* Mark Wright wrote on Fri, Jun 13, 2008 at 01:20:57PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Generally, if you want to have several versions of some library at the
> > same time, put them in distinct $prefix'es, apart from other
> > libraries. That helps to minimize s
Hello Alon, Bob, all,
* Bob Friesenhahn wrote on Thu, Jun 12, 2008 at 10:07:39PM CEST:
>
> The best path forward is that if you feel strongly enough about this,
> then prepare a patch for libtool which works for you.
That's necessary, but typically not sufficient, unfortunately. ;-)
> The pat
Thank you for your response.
As long as it is in the future TODO list it is good I am waiting for
this for a long time. If it was difficult to you guys, imagine how it
is for someone external...
Building packages into chroot is more and more common, live-cd,
live-usb, initramfs, embedded, vserver
* Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 09:59:06AM CEST:
> As far as I know libtool is the only tool that needs fixups or
> workaround. If there is any formal workaround for this I will be happy
> to know, my sample implementation is available at [1]. I will be happy
> to modify it if there is
Hello Alon, and sorry for the delay,
* Alon Bar-Lev wrote on Fri, Jun 06, 2008 at 09:15:37AM CEST:
> > > I want to make a shared library without dependencies. I compile the
> > > dependencies in PIC mode, so it should be compatible.
> Let's say I have liba.la pointing to liba.so* and liba.a(pic
Thank you for explaining this.
I still don't understand why the developer cannot make the decision if
it is proper or not.
The -static-libtool-libs can be used for this as-well. If it absent
(default) current behavior apply, but if it is specify on shared
library then it should behave consistently
* Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:08:47AM CEST:
> I still don't understand why the developer cannot make the decision if
> it is proper or not.
> The -static-libtool-libs can be used for this as-well. If it absent
> (default) current behavior apply, but if it is specify on shared
> li
On 6/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> I would like to create a program that links against your PKCS#11
> provider DLL, and for some reason, I also need to link against OpenSSL
> or some other library from which you have put code into the DLL.
> If I understand your example ab
* Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:36:03AM CEST:
> On 6/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > I would like to create a program that links against your PKCS#11
> > provider DLL, and for some reason, I also need to link against OpenSSL
> > or some other library from wh
On 6/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 11:36:03AM CEST:
>
> > On 6/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > I would like to create a program that links against your PKCS#11
> > > provider DLL, and for some reason, I a
On Sat, 14 Jun 2008, Alon Bar-Lev wrote:
As far as I understand, if I have PKCS#11 provider (library) with
OpenSSL linked within it, and application loads it, there is not
symbol mixups, as the symbols of embedded OpenSSL implementation are
not exposted to the application. And as the interface be
12 matches
Mail list logo
