Assignee: unassigned at sourceware dot org
Reporter: yselkowitz at cygwin dot com
Host: x86_64-cygwin, x86_64-redhat-linux
Target: sh64-elf
Build: x86_64-cygwin, x86_64-redhat-linux
1) Build binutils-2.25 with --target=sh64-elf and install
2
Assignee: unassigned at sourceware dot org
Reporter: yselkowitz at cygwin dot com
CC: ktietz at redhat dot com, nickc at redhat dot com
Host: x86_64-redhat-linux (RHEL/CentOS 6)
Target: {i686,x86_64}-w64-mingw32
Build: x86_64-redhat
https://sourceware.org/bugzilla/show_bug.cgi?id=17753
--- Comment #3 from Cygwin/X maintainer ---
Created attachment 8024
--> https://sourceware.org/bugzilla/attachment.cgi?id=8024&action=edit
Proposed patch
Please consider this patch for master and the 2.25 branch.
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=17753
--- Comment #2 from Cygwin/X maintainer ---
(In reply to Alan Modra from comment #1)
> I don't see the failure here. Are you picking up the wrong libopcodes.so?
I built this with static libbfd/libopcodes. However, now that you mention it,
I
: unassigned at sourceware dot org
Reporter: yselkowitz at cygwin dot com
Host: x86_64-cygwin
Target: mep-elf
Build: x86_64-cygwin
Created attachment 8023
--> https://sourceware.org/bugzilla/attachment.cgi?id=8023&action=edit
result of mep-elf gcc/
https://sourceware.org/bugzilla/show_bug.cgi?id=16792
--- Comment #2 from Cygwin/X maintainer ---
When a sysroot is in use, libraries usually end up in =/lib and =/usr/lib (or
=/mingw/lib for *-*-mingw*), but $exec_prefix/$target_alias/lib has still been
scanned. Not only is that not happening a
https://sourceware.org/bugzilla/show_bug.cgi?id=16821
Cygwin/X maintainer changed:
What|Removed |Added
CC||yselkowitz at cygwin dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16807
Cygwin/X maintainer changed:
What|Removed |Added
CC||yselkowitz at cygwin dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16790
Cygwin/X maintainer changed:
What|Removed |Added
CC||corinna at vinschen dot de,
Assignee: nickc at redhat dot com
Reporter: yselkowitz at cygwin dot com
Nick,
A possibly unforeseen side-effect has resulted from the addition of
default-manifest support for PE targets. Usually, a simple '[$target-]ld -v'
only prints the version, and '[$targe
Component: ld
Assignee: nickc at redhat dot com
Reporter: yselkowitz at cygwin dot com
Created attachment 7493
--> https://sourceware.org/bugzilla/attachment.cgi?id=7493&action=edit
patch for binutils-gdb.git master
Now that ld/Makefile.am calls WINDRES_FOR_TARGET in
--- Additional Comments From yselkowitz at cygwin dot com 2009-04-02 03:45
---
(In reply to comment #9)
> It also mentions --e-a-s in the --export-dynamic documentation.
"PE targets support a similar function to export all symbols from a DLL;"
or EXE, which is actually
--- Additional Comments From yselkowitz at cygwin dot com 2009-04-01 16:18
---
Chuck has pushed the corresponding libtool patch upstream, so this should handle
many cases where it would be used. I suppose a warning would be appropriate, as
would clarification in the documentation on
--- Additional Comments From yselkowitz at cygwin dot com 2009-03-24 06:45
---
> It would certainly be technically correct if libtool chose to use --e-a-s
> rather than --e-d when linking for a cygwin target, since it's the target-
> specific equivalent.
Good point, ch
--- Additional Comments From yselkowitz at cygwin dot com 2009-03-24 02:02
---
(In reply to comment #2)
> --export-dynamic is an ELF format option, and --export-all-symbols is the PE
> equivalent.
Dave, thanks for looking at this. The ld texinfo docs say nothing about
--export-d
--
What|Removed |Added
Version|2.19|2.20 (HEAD)
http://sourceware.org/bugzilla/show_bug.cgi?id=6744
--- You are receiving this mail because:
16 matches
Mail list logo
