Ralf Wildenhues wrote:
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
While Ralf's point about static data is valid, the functions likely to
be in libiberty on any platform supporting plugins should not suffer
from this problem.
Solaris 9 and IRIX 6.5 support dlopen
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
> While Ralf's point about static data is valid, the functions likely to
> be in libiberty on any platform supporting plugins should not suffer
> from this problem.
Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as mi
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
> Daniel Jacobowitz wrote:
> >On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
> >>In simpler words, *.so have to be compiled with -fPIC, and libiberty
> >>is not compiled with -fPIC.
> >
> >We build a PIC li
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty already.
Thanks!
Where and how is it built? I cannot find any
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
> In simpler words, *.so have to be compiled with -fPIC, and libiberty
> is not compiled with -fPIC.
We build a PIC libiberty already.
While Ralf's point about static data is valid, the functions likely to
be in libiberty on an
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 02:50:04PM CEST:
> On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
> > But it seems to me that a plugin can call a libliberty function only if that
> > function is already referenced (e.g. called) from cc1. This is not the case
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
of all libiberty functions.
So... link
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
> But it seems to me that a plugin can call a libliberty function only if that
> function is already referenced (e.g. called) from cc1. This is not the case
> of all libiberty functions.
So... link libiberty into your plugin and
Dave Korn wrote:
Basile STARYNKEVITCH wrote:
Dave Korn wrote:
We might also artificially add a reference to each libiberty function
from
cc1.
Or link it into cc1 et al. using "--whole-archive".
Sorry, I am not aware of this option. And are we sure it works o
Basile STARYNKEVITCH wrote:
> Dave Korn wrote:
>>
>>> We might also artificially add a reference to each libiberty function
>>> from
>>> cc1.
>>
>> Or link it into cc1 et al. using "--whole-archive".
>>
>>
> Sorry, I am not aware of this option. And are we sure it works on all
> the syste
Dave Korn wrote:
We might also artificially add a reference to each libiberty function from
cc1.
Or link it into cc1 et al. using "--whole-archive".
Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to run on?
If we did link dynami
Basile Starynkevitch wrote:
> Hello All,
>
> Perhaps libiberty should be a shared library, not a static one, linked from
> cc1, when GCC has plugin enabled.
> We might also artificially add a reference to each libiberty function from
> cc1.
Or link it into cc1 et al. using "--whole-archive".
Hello All,
Perhaps libiberty should be a shared library, not a static one, linked from
cc1, when GCC has plugin enabled.
I noticed the following in the MELT branch (while trying to build MELT as a
GCC-Trunk plugin).
Some functions of libiberty.h are not linked in cc1 (because cc1 don't call
them
14 matches
Mail list logo
