hen invoke the linker.
I am thinking of fixing it.
--
Regards
Rishi
>
> Honza
> > --
> > Regards
> > Rishi
> >
> > >
> > > I am also adding Ian to CC as he is maintainer of the simple-object and
> > > he may have some ideas.
> > >
> &g
gt; Rishi
>
> >
> > I am also adding Ian to CC as he is maintainer of the simple-object and
> > he may have some ideas.
> >
> > Honza
> > >
> > > /* Release all resources associated with SIMPLE_OBJECT, including any
> > > simple_objec
port first, I am adding
> .symtab
> > in elf object files only.
> >
> > ---
> > gcc/lto-object.cc | 4 +-
> > include/simple-object.h | 10 +++
> > libiberty/simple-object-common.h | 18 +
> > libiberty/simple-object-elf.c
ion in simple-object.c to add symbols. I am
> calling this function in lto-object.cc to add __gnu_lto_v1.
> Right now, as we are only working on ELF support first, I am adding .symtab
> in elf object files only.
>
> ---
> gcc/lto-object.cc| 4 +-
> include/sim
| 4 +-
include/simple-object.h | 10 +++
libiberty/simple-object-common.h | 18 +
libiberty/simple-object-elf.c| 130 +++++--
libiberty/simple-object.c| 32
5 files changed, 187 insertions(+), 7 deletions(-)
diff --git a/gcc/l
On 25.07.2022 17:45, ibuc...@gdcproject.org wrote:
>> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>>
>>
>> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
>>>> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>>>> while commit 3f30a274913b ("
> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>
>
> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
> >> On 25/07/2022 08:45 CEST Jan Beulich wrote:
> >> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> >> for latest ABI s
On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
>> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>> while commit 3f30a274913b ("libiberty: Update D symbol demangling
>> for latest ABI spec") mentions in its description that tuple encoding
>> has chan
> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>
>
> Hello,
>
> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> for latest ABI spec") mentions in its description that tuple encoding
> has changed, there's no real adjustment to dlang_p
Hello,
while commit 3f30a274913b ("libiberty: Update D symbol demangling
for latest ABI spec") mentions in its description that tuple encoding
has changed, there's no real adjustment to dlang_parse_tuple() there,
nor are there any new (or replaced) test cases for that. Was this
si
)
>>> configure: WARNING: cannot check for properly working vsnprintf when
>>> cross compiling, will assume it's ok
>>> ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>>> ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ outpu
rintf when
>> cross compiling, will assume it's ok
>> ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>> ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>> truncated before terminating nul copying as many bytes from a string
&g
On 3/23/19 9:49 PM, nick wrote:
Greetings all,
I just got this in my build output:
ar: `u' modifier ignored since `D' is the default (see `U')
configure: WARNING: cannot check for properly working vsnprintf when cross
compiling, will assume it's ok
../../gcc/libiberty/dyn-s
vsnprintf when cross
compiling, will assume it's ok
../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
On Fri, Jul 29, 2016 at 1:44 PM, Joseph Myers wrote:
> On Fri, 29 Jul 2016, Manuel López-Ibáñez wrote:
>
>> On 29 July 2016 at 16:25, Jeff Law wrote:
>> >> Well, if libiberty is going to be replaced en masse by gnulib, then
>> >> there's no
On Fri, 29 Jul 2016, Manuel López-Ibáñez wrote:
> On 29 July 2016 at 16:25, Jeff Law wrote:
> >> Well, if libiberty is going to be replaced en masse by gnulib, then
> >> there's no sense in me cleaning up libiberty's regex.
>
> libiberty cannot be replac
On 29 July 2016 at 16:25, Jeff Law wrote:
>> Well, if libiberty is going to be replaced en masse by gnulib, then
>> there's no sense in me cleaning up libiberty's regex.
libiberty cannot be replaced completely, because there are bits that
do not even exist in gnulib. And g
ok to
resync
with glibc, though that could prove painful after 15 years of
divergence.
The current glibc implementation is completely different; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
prove painful after 15 years of
divergence.
The current glibc implementation is completely different; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
glibc regex that way
BTW, this is what Ayu
On Fri, 29 Jul 2016, Aldy Hernandez wrote:
> BTW, does this libiberty replacement project also fix binutils and gdb, or
> will these other libiberty users require independent patches for their
> respective projects?
GDB is already making extensive use of gnulib (I don't know to w
prove painful after 15 years of
divergence.
The current glibc implementation is completely different; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
glibc regex that way
BTW, this is what Ayu
rrent glibc implementation is completely different; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
glibc regex that way
BTW, this is what Ayush is trying to do:
https://gcc.gnu.org/m
; the libiberty
version was replaced in glibc many years ago. Obsolete libiberty by
gnulib for all its users and you get a portable version of the current
glibc regex that way
BTW, this is what Ayush is trying to do:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html
https://gcc.gnu.org
On Mon, 25 Jul 2016, Jeff Law wrote:
> I'll pre-approve removing those bits. Alternately, you could look to resync
> with glibc, though that could prove painful after 15 years of divergence.
The current glibc implementation is completely different; the libiberty
version was replac
ely, you could look to
resync with glibc, though that could prove painful after 15 years of
divergence.
Another silly question, who are libiberty's consumers? GCC and
binutils/gdb? Or should I be looking at additional packages for answers?
Packages which have libiberty included are supp
On 07/23/2016 06:33 AM, Aldy Hernandez wrote:
If the REGEX_MALLOC mode in regex.c is unused, can I rip it out? I'd
like to replace it all with alloca with a malloc fallback.
And yes, I realize regex.c already does this most of the time:
if (size1 > MAX_ALLOCA_SIZE)
{
t look like autoconf magic being set elsewhere.
The only reference I see to REGEX_MALLOC is in libiberty/regex.c:
/* Should we use malloc or alloca? If REGEX_MALLOC is not defined, we
use `alloca' instead of `malloc'. This is because using malloc in
re_search* or re_match* cou
On Mon, 11 Jul 2016, Ian Lance Taylor wrote:
> > AFAICT, the only "utilities" found in libiberty not appropriate for
> > gnulib is the demangler. That would be more appropriate for a
> > libdemangler library shared among all gnutools.
>
> Does gnulib have a fu
aling either. Considering that the long
>>> term desired result ends up with a libiberty that is no longer a
>>> portability library, but instead only an utilities library, then to
>>> get to that stage, the other programs in the binutils-gdb repo which
>>> rely
e: they have a separate repo for Clang (the frontend, ~ gcc/c, cp,
> ...), for compiler-rt (~ libgcc), for libc++ (~ libstdc++).
>
> All utilities (~ libiberty) live in the LLVM repo (include/llvm/ADT,
> include/llvm/Support, lib/Support). Other projects, like LLDB, are checked out
> i
On Sun, Jul 10, 2016 at 10:15 AM, Manuel López-Ibáñez
wrote:
> On 23 June 2016 at 18:02, Pedro Alves wrote:
>> But on the other hand, the idea of maintaining multiple gnulib
>> copies isn't that appealing either. Considering that the long
>> term desired result ends u
r-rt (~ libgcc), for libc++ (~ libstdc++).
All utilities (~ libiberty) live in the LLVM repo (include/llvm/ADT,
include/llvm/Support, lib/Support). Other projects, like LLDB, are checked out
into a subdirectory, and are always built from the combined tree.
--
Regards,
Mikhail Maltsev
On 23 June 2016 at 18:02, Pedro Alves wrote:
> But on the other hand, the idea of maintaining multiple gnulib
> copies isn't that appealing either. Considering that the long
> term desired result ends up with a libiberty that is no longer a
> portability library, but instead
On 06/23/2016 03:54 PM, Szabolcs Nagy wrote:
> if both gcc and binutils used a toplevel gnulib directory
> then shared tree build would have the same problem as
> libiberty has now: gcc and binutils can depend on different
> versions of libiberty and then the build can fail.
> a
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=tree;f=gdb/gnulib;h=cdf326774716ae427dc4fb47c9a410fcdf715563;hb=HEAD
>
> ... but put it in the top level instead.
if both gcc and binutils used a toplevel gnulib directory
then shared tree build would have the same problem as
On 06/22/2016 07:17 PM, ayush goel wrote:
>
> Hi, I am working on importing gnulib library inside the gcc tree.
> Should the library be imported in the top level directory along with
> other libraries (like libiberty, libatomic, liboffloadmic etc), or
> should it be imported insi
On Wed, 22 Jun 2016, ayush goel wrote:
> I am working on importing gnulib library inside the gcc tree. Should the
> library be imported in the top level directory along with other
> libraries (like libiberty, libatomic, liboffloadmic etc), or should it
> be imported inside gcc/ lik
Hi,
I am working on importing gnulib library inside the gcc tree. Should the
library be imported in the top level directory along with other libraries (like
libiberty, libatomic, liboffloadmic etc), or should it be imported inside gcc/
like it is done in the binutils-gdb tree. There they have
On Fri, 2013-03-29 at 06:13 -0700, Ian Lance Taylor wrote:
> On Fri, Mar 29, 2013 at 1:35 AM, Matt Burgess
> wrote:
> >
> > 1) We currently assume that binutils is 'upstream' for libiberty
> > development, and should therefore 'own' the libiberty.a fi
On Fri, Mar 29, 2013 at 1:35 AM, Matt Burgess
wrote:
>
> 1) We currently assume that binutils is 'upstream' for libiberty
> development, and should therefore 'own' the libiberty.a file. Is that
> assumption correct?
No. The master sources for libiberty are
estions:
1) We currently assume that binutils is 'upstream' for libiberty
development, and should therefore 'own' the libiberty.a file. Is that
assumption correct?
2) The --disable-install-libiberty configure switch for GCC does *not*
suppress the installation of libiberty.a (s
> > Note that one of the objectives of this email is to try and get
> > maintainers from thinking there is going to be "a perfect time" to
> > switch. Development history tells us there will always be more
> > changes. We've been sitting on ABI-breaking changes since 2003.
>
> e.g. http://gcc.gnu
On 13 January 2012 17:45, Benjamin Kosnik wrote:
>
> Note that one of the objectives of this email is to try and get
> maintainers from thinking there is going to be "a perfect time" to
> switch. Development history tells us there will always be more changes.
> We've been sitting on ABI-breaking ch
> My concern is specifically about options for changing the default
> language version, not options for changing the libstdc++ ABI. More
> generally, about configure options affecting the semantics of code
> passed to GCC, as opposed to non-semantic configure options such as
> choosing the proces
> > As it turns out, the mangling changes don't really impact the
> > explicit instantiations compiled in to libstdc++.so. So, it seems
> > possible to say
>
> Right, so people can use -fabi-version=0 and still use the installed
> libstdc++.
>
> > I think a compelling case could be made to ship
On Fri, 13 Jan 2012, Benjamin Kosnik wrote:
> A canonical method for doing the ABI switch seems entirely appropriate.
My concern is specifically about options for changing the default language
version, not options for changing the libstdc++ ABI. More generally,
about configure options affectin
> I like the idea, but not very strongly. I can live with having to say
> -std=c++11 (which I do via shell functions or scripts)
Well, the actual C++11 compile/runtime environment is going to be more
than just -std=c++11. It's looking something like -std=c++11
-fabi-version=7 + versioned names
> I think that's a bad idea; having too many ways to configure things
> will cause undue confusion.
Seems like the train has already left the station WRT gcc configure
options. If you feel this is a real issue, then it could be solved the
same way that thread support was solved, by adding a "Th
On 12 January 2012 21:03, Jason Merrill wrote:
> On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
>>
>> And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
>> not be able to change anything significant in .so.7 once it's
>> available in 4.7 and we'll have to create a .so.8 for more
On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
not be able to change anything significant in .so.7 once it's
available in 4.7 and we'll have to create a .so.8 for more changes..
Wait, what? Are you planning to move to .so.7
On 01/12/2012 02:16 PM, Benjamin Kosnik wrote:
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
Right, so people can use -fabi-version=0 and still use the installed
libstdc++.
I think a compelling
On 12 January 2012 19:16, Benjamin Kosnik wrote:
>
> I think a compelling case could be made to ship 4.7 with a
> configure-time flag that sets the default C++ dialect to C++11.
>
> So, I would propose
>
> --with-std = dialect
>
> or
>
> --with-std-version=c dialect default, c++ dialect default
>
>
On Thu, 12 Jan 2012, Benjamin Kosnik wrote:
> I think a compelling case could be made to ship 4.7 with a
> configure-time flag that sets the default C++ dialect to C++11.
I think that's a bad idea; having too many ways to configure things will
cause undue confusion. But if someone really wants
> bkoz pointed out that I forgot to update invoke.texi about
> -fabi-version=6. Applying to trunk
I've been thinking about this.
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
1. compile libstdc++
On Sun, 30 Oct 2011, Michael Eager wrote:
> On 10/29/2011 11:55 PM, Michael Eager wrote:
> > On 10/29/2011 08:44 PM, Ian Lance Taylor wrote:
> > > Michael Eager writes:
> > >
> > > > I'm seeing a build failure when building a bootstrap gcc
> > >
On 10/29/2011 11:55 PM, Michael Eager wrote:
On 10/29/2011 08:44 PM, Ian Lance Taylor wrote:
Michael Eager writes:
I'm seeing a build failure when building a bootstrap gcc
because it is attempting to build target-libiberty. This
is happening for --target=powerpc-linux with the gcc-
On 10/29/2011 08:44 PM, Ian Lance Taylor wrote:
Michael Eager writes:
I'm seeing a build failure when building a bootstrap gcc
because it is attempting to build target-libiberty. This
is happening for --target=powerpc-linux with the gcc-4.6.1
release and --target=microblaze-xilinx-elf
Michael Eager writes:
> I'm seeing a build failure when building a bootstrap gcc
> because it is attempting to build target-libiberty. This
> is happening for --target=powerpc-linux with the gcc-4.6.1
> release and --target=microblaze-xilinx-elf with gcc-4.6.2.
>
> Target
Hi --
I'm seeing a build failure when building a bootstrap gcc
because it is attempting to build target-libiberty. This
is happening for --target=powerpc-linux with the gcc-4.6.1
release and --target=microblaze-xilinx-elf with gcc-4.6.2.
Target-libiberty is not being built when building
On Wednesday, January 05, 2011 11:44:58 Mike Frysinger wrote:
> On Tuesday, January 04, 2011 13:03:59 H.J. Lu wrote:
> > libiberty/.gitignore was added to src. But it isn't in gcc tree.
>
> i dont have access to the gcc tree, so i can only post patches. if someone
> wer
On Tuesday, January 04, 2011 13:03:59 H.J. Lu wrote:
> libiberty/.gitignore was added to src. But it isn't in gcc tree.
i dont have access to the gcc tree, so i can only post patches. if someone
were to grant me access, i obviously wouldnt have a problem making the commit.
otherwise
Hi,
libiberty/.gitignore was added to src. But it isn't in gcc tree.
--
H.J.
oops, also need like:
--- /src/orig/gcc-4.5.0/libiberty/configure 2010-01-04 15:46:56.0
-0800
+++ /src/gcc-4.5.0/libiberty/configure 2010-05-05 05:40:52.0 -0700
@@ -6533,10 +6533,10 @@
# Figure out which version of pexecute to use.
case "${host}" in
-
> CC: gcc@
> From: iant@
>
> Jay:
>> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to
>> $(OBJEXT).
>
> Yes.
>
> Ian
Thanks.
Specifically ".o" goes to "@objext@".
There's no way I'
> Use #ifdef HAVE_UNISTD_H instead. There are many examples in
> libiberty.
>
> Ian
Thanks Ian, that worked.
--- /src/orig/gcc-4.5.0/libiberty/pex-common.h 2009-04-13 03:45:58.0
-0700
+++ /src/gcc-4.5.0/libiberty/pex-common.h 2010-05-04 06:43:24.0 -0700
@@
Jay K writes:
> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to
> $(OBJEXT).
Yes.
Ian
Jay K writes:
> proposed/tested fix:
> #ifdef __vms
> #include
> #endif
>
> or similar.
Use #ifdef HAVE_UNISTD_H instead. There are many examples in
libiberty.
Ian
I'm guessing that every ".o" in libiberty/Makefile.in should be changed to
$(OBJEXT).
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Mon
./strverscmp.obj ./vasprintf.obj ./vfork.obj
./strncmp.obj
alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
make: *** [libiberty.a] Error 1
jbook2:libiberty jay$ edit Makefile
alpha-dec-gcc -c foo.c outputs foo.obj.
"Something" seems to know this, since:
libiberty/Makefile.i
In file included from /src/gcc-4.5.0/libiberty/pex-common.c:23:0:
/src/gcc-4.5.0/libiberty/pex-common.h:73:3: error: expected
specifier-qualifier-list before 'pid_t'
the code:
/* pid_t is may defined by config.h or sys/types.h needs to be
included. */
#if !defined(pid_t)
> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
> (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
> (plus:SI (subreg/s:SI (reg/v
On Mon, 1 Mar 2010, DJ Delorie wrote:
> > But I've previously noted that target libiberty seems completely useless;
>
> It's a target library, like newlib, libz, libstdc++, or anything else.
> How do you know there are no target applications that want to link
> again
> Is it still used outside the "Cygnus tree"?
How should I know? I don't know what users of free software do with
it...
It's a target library. Anyone writing code for any target might use
it.
On 03/01/2010 09:48 PM, DJ Delorie wrote:
But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
Is it still us
> But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
On Mon, 1 Mar 2010, Jack Howarth wrote:
> Somehow the recursive make is broken for libiberty and is silently using
> the system compiler.
> Jack
I believe this is PR29404. IIRC, in addition to libiberty, other
recursive "make check"s fail too due to using
x86_64-apple-darwin9 or i686-apple-darwin10, I
> > noticed
> > that we seem to build libiberty both at the toplevel and within the multilib
> > subdirectories (x86_64-apple-darwin9 and i686-apple-darwin10 respectively).
> > Is this expected behavior as I don't see
r i686-apple-darwin10, I
> > noticed
> > that we seem to build libiberty both at the toplevel and within the multilib
> > subdirectories (x86_64-apple-darwin9 and i686-apple-darwin10 respectively).
> > Is this expected behavior as I don't see anything other than libibe
Jack Howarth writes:
>While looking at PR42308 and trying to understand why the make check
> is leaky and starts to call the system compiler instead of the xgcc during
> a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
> that we seem to build libib
While looking at PR42308 and trying to understand why the make check
is leaky and starts to call the system compiler instead of the xgcc during
a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
that we seem to build libiberty both at the toplevel and within the
> Your code uses the (one and only) CRC-32 polynomial 0x04c11db7, so just
> describing it as the "CRC-32" function should be sufficient documentation.
> It's the same CRC function as used by PKZIP, Ethernet, and chksum.
> It's not compatible with the Intel CRC32 instruction which uses the
> CRC-32
DJ Delorie writes:
>I didn't reference the web site for the polynomial, just for background.
>To be honest, I'm not sure what the polynomial is. As the comments
>explain, the algorithm I used is precisely taken from gdb, in remote.c,
>and is intended to produce the same result. Does anybody on th
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 su
* 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 doc
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
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 -
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 l
This is not the case
> > of all libiberty functions.
>
> So... link libiberty into your plugin and get make_temp_file that way.
Ahh, another opportunity for subtle bugs stemming from multiple entities
of static data, such as random numbers used in a plugin being
suspiciously correlated to
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
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 yo
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 sur
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".
>>
>>
> So
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 w
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. usin
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
Eli Zaretskii writes:
> 2009-04-14 Eli Zaretskii
>
> * configure.ac (setobjs, msdosdjgpp): Move a-priori setting of
> existing and required library functions to with_target_subdir
> section, so that the native build does detect them at configure
> time.
This is OK.
T
On Tue, 14 Apr 2009, Eli Zaretskii wrote:
> The following snippet from libiberty/Makefile.in:
>
> # needed-list is used by libstdc++. NEEDED is the list of functions
> # to include there. Do not add anything LGPL to this list; libstdc++
> # can't use anything
The following snippet from libiberty/Makefile.in:
# needed-list is used by libstdc++. NEEDED is the list of functions
# to include there. Do not add anything LGPL to this list; libstdc++
# can't use anything encumbering.
NEEDED = atexit calloc memchr memcmp memcpy memmove m
The following snippet from libiberty/Makefile.in:
# needed-list is used by libstdc++. NEEDED is the list of functions
# to include there. Do not add anything LGPL to this list; libstdc++
# can't use anything encumbering.
NEEDED = atexit calloc memchr memcmp memcpy memmove m
1 - 100 of 207 matches
Mail list logo
