https://sourceware.org/bugzilla/show_bug.cgi?id=28045
--- Comment #1 from Ben Woodard ---
Some additional things to consider:
https://wiki.c2.com/?DontCatchExceptions
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Re-catch
https://github.com/isocpp/CppCoreGuidelines
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: woodard at redhat dot com
Target Milestone: ---
Right now given some random library it is very difficult and requires an awful
amount of digging to just figure out what you should try to catch. It would be
great if
Assignee: unassigned at sourceware dot org
Reporter: woodard at redhat dot com
Target Milestone: ---
One thing that is an important aspect of compatibility between libraries and
their consumers (apps and other libraries) are the exceptions thrown and
caught. Ideally you want to
https://sourceware.org/bugzilla/show_bug.cgi?id=26706
Ben Woodard changed:
What|Removed |Added
CC|mcermak at redhat dot com |
--
You are receiving this mail
https://sourceware.org/bugzilla/show_bug.cgi?id=26706
Ben Woodard changed:
What|Removed |Added
CC||mcermak at redhat dot com
--
You are r
https://sourceware.org/bugzilla/show_bug.cgi?id=26706
Ben Woodard changed:
What|Removed |Added
CC|mcermak at redhat dot com |
--
You are receiving this mail
https://sourceware.org/bugzilla/show_bug.cgi?id=26706
Ben Woodard changed:
What|Removed |Added
CC||mcermak at redhat dot com
--
You are r
https://sourceware.org/bugzilla/show_bug.cgi?id=26706
--- Comment #3 from Ben Woodard ---
Do you think it is worth me chiming in saying ‘what he said’? You captured my
intent perfectly. I guess I’m kind of hung up on “assume” in “what I assume
Ben, the original reporter, is after” or is that jus
Assignee: unassigned at sourceware dot org
Reporter: woodard at redhat dot com
Target Milestone: ---
There are times where it is necessary to patch ELF files so that they have
correct paths to things. Most of the things that they want to be able to update
are in the .dynstr section e.g. RPATH
https://sourceware.org/bugzilla/show_bug.cgi?id=26595
--- Comment #5 from Ben Woodard ---
Nick I must apologize; fche straightened me out.
The reason why fche discovered this bug, and the reason why I was testing it
with boost is I have a report of a problem report with boost location lists. So
https://sourceware.org/bugzilla/show_bug.cgi?id=26595
--- Comment #4 from Ben Woodard ---
A similar problem with readelf
$ readelf --debug-dump=loc,follow-links /lib64/libboost_system.so.1.69.0 > foo
$ ~/bin/readelf --debug-dump=loc,follow-links /lib64/libboost_system.so.1.69.0
> bar
$ diff -u
https://sourceware.org/bugzilla/show_bug.cgi?id=26595
--- Comment #3 from Ben Woodard ---
Nick I may be doing something wrong but I'm not able to reproduce fche's
success. It appears like it is following those links which is good but it
doesn't appear to be successfully using them:
Latest trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=20755
Ben Woodard changed:
What|Removed |Added
CC||woodard at redhat dot com
--
You are
13 matches
Mail list logo
