[Bug ld/13557] Undef. ref. err. when linking with slim LTO obj. in static lib. (mingw32 target)

[lrn1986 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13557



--- Comment #6 from LRN  ---

Created attachment 7566

  --> https://sourceware.org/bugzilla/attachment.cgi?id=7566&action=edit

A hack to fix lto linking



Built binutils with debuginfo on Debian, compared with what runs on Windows.



elf_link_add_archive_symbols() just loops through all archive symbols and c
alls

> if (!(*info->callbacks

>   ->add_archive_element) (info, element, symdef->name, &element))

for each one of them. It only needs element to be non-NULL, and to have the

bfd_object format.



_bfd_generic_link_add_archive_symbols(), on the other hand, does the checks

detailed above AND calls

> if (! (*checkfn) (element, info, &needed))

>   goto error_return;

*checkfn is coff_link_check_archive_element(), it calls

coff_link_check_ar_symbols(), which i've examined earlier.



Here's a hack that forces coff_link_check_ar_symbols() to recognize gnu lto

symbol names. My guess is that a non-hacky version should consult the plugin

(maybe call claim_file() over element or something?).



-- 

You are receiving this mail because:

You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/16480] make doesn't work Mac X OS 10.9.1

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16480

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com
  Component|build   |binutils
Version|7.6 |unspecified
Product|gdb |binutils

--- Comment #1 from Pedro Alves  ---
opcodes/i386-dis.c is "owned" by binutils.  Changing "product".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13557] Undef. ref. err. when linking with slim LTO obj. in static lib. (mingw32 target)

[lrn1986 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13557



--- Comment #7 from LRN  ---

No, this does not work. For real-life cases (libcairoboilerplate) ar symbol

table consists of multiple copies of ___gnu_lto_v1 and ___gnu_lto_slim or

somesuch.

The

>  arh = archive_hash_lookup (&arsym_hash, h->root.string, FALSE, FAL
SE);

lookup never considers them to be candidates for resolving undefined

references, thus 

> if (! (*checkfn) (element, info, &needed))

is never called.



Need to look further.



-- 

You are receiving this mail because:

You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/16858] weak external reference has wrong value

[bernd.edlinger at hotmail dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=16858

Bernd Edlinger  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Bernd Edlinger  ---
Hi, I installed your patch on a 2.24 binutils, and
I am still having trouble with the following example:
(on i686-cygwin-32)

$ gcc test0.c
$ ./a
hello
weak
hello
weak
hello
weak
hello
weak
hello
weak
...

$ gcc test0.c test1.c
$ ./a
hello
strong
Segmentation fault (Speicherabzug geschrieben)


the first direct call to test is OK now, but the second
using pointer (weak reference!) still does not work.
I am afraid the second use-case is what GCC will use.

$ cat  test0.c
#include 

extern void test() __attribute__((weak));

int main()
{
  void (*f)();
  printf("hello\n");
  test();
  f = &test;
  if (f != NULL)
(*f)();
  else
printf("no weak\n");
  return 0;
}

#if 1
//__attribute__((weak,section("test1")))
void test()
{
  printf("weak\n");
}
#endif

$ cat test1.c
#include 

void test()
{
  printf("strong\n");
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/16480] make doesn't work Mac X OS 10.9.1

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16480

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from H.J. Lu  ---
Binutils 2.24 has

/* Like oappend (below), but S is a string starting with '%'.
   In Intel syntax, the '%' is elided.  */
static void
oappend_maybe_intel (const char *s)
{
  oappend (s + intel_syntax);
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13557] Undef. ref. err. when linking with slim LTO obj. in static lib. (mingw32 target)

[lrn1986 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13557

LRN  changed:

   What|Removed |Added

   Attachment #7566|0   |1
is obsolete||

--- Comment #8 from LRN  ---
Created attachment 7567
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7567&action=edit
A hack to fix lto linking

v2:
* fixed a stupid buffer size bug (should have read the code before re-using
macros...)
* fixed an error where symbol might get mischopped if it had too many '.' in it
(now uses strrchr to find the last dot).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils