[Bug binutils/6733] New: Inconsistent default behaviour of dialog controls (windres)
For some control elements (AUTOCHECKBOX, AUTO3STATE, AUTORADIOBUTTON, ...) the base_style differs from the default_style (eg. no WS_TABSTOP). For some others (CHECKBOX, ...) they are the same (implemented in rcparse.c). This causes different behaviour depending on whether one specifies a style for the control in a resource script or not. Especially the behaviour differs from the MS resource compiler. Example: AUTOCHECKBOX "", 10, 5, 5, 50, 10, WS_GROUP keeps its WS_TABSTOP when compiled with MS' rc.exe, looses its WS_TABSTOP when compiled with windres.exe seen with windres version: 2.18.50. 20080109 -- Summary: Inconsistent default behaviour of dialog controls (windres) Product: binutils Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: michael dot hentschel at gmx dot at CC: bug-binutils at gnu dot org GCC build triplet: 2.18.50 http://sourceware.org/bugzilla/show_bug.cgi?id=6733 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6734] New: LD Symbol Export issues for x86
Hello I am from a project primarily aimed for x86. We strive to have our codebase compilable with more than one compiler/linker, but unfortunately there is a problem. LD requires exported functions in .def to be decorated, like: [EMAIL PROTECTED] @[EMAIL PROTECTED] instead of simply Foobar Fastcallfoo The symbol decoration is not compatible with, for example, MSVC's linker, requiring us to maintain .def files with and without symbol decoration for each library (and we have quite a bit of them). I do not know much about the internal workings of compilers and linkers, and have been unable to find out why this issue exists. Why does LD require this .def symbol decoration, and could it perhaps be possible to fix? -- Summary: LD Symbol Export issues for x86 Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: Stefan__100__ at hotmail dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6734 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6734] LD Symbol Export issues for x86
--- Additional Comments From Stefan__100__ at hotmail dot com 2008-07-10 16:07 --- UPDATE Okay, just had more info about the issue. The libraries are properly compiled to export the symbols as we want them (without decorations). However, when the libraries link to each other, they try to import symbols with @nn decoration. So, the problem seems to be that a combination of --kill-at and --enable-stdcall-fixup do not work correctly. Perhaps there may be a small bug somewhere? -- http://sourceware.org/bugzilla/show_bug.cgi?id=6734 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Version intricacies for installing binutils
Hello, people On 7/11/08, wim <[EMAIL PROTECTED]> wrote: >I get back to the binutils problems >You suggested me to use the original gcc and as >(SUSE 8.0 distribution) >About these versions I have >gcc --version >2.95.3 >as --version >GNU assembler 2.11.92.0.10 (SuSE) >Copyright 2001 Free Software Foundation, Inc. >This program is free software; you may redistribute it under the terms of >the GNU General Public License. This program has absolutely no warranty. >This assembler was configured for a target of `i486-suse-linux'. >So I started from the very beginning >Unfortunately make stops again too early >I attach all config.* files from bfd >I hope you could give me a further advice. I saw a similar problem on RedHat 7.3 (it comes with gcc-2.96). I think it is somewhere in makeinfo detection. I solved this via either 1) using binutils-2.17 instead of binutils-2.18 2) editing the Makefiles so that not to build documentation in bfd 3) dirtily patching binutils-2.18/missing (I realize this is almost certainly not the right file, but it just worked for me): --- binutils-2.18/missing 2005-07-14 05:24:56.0 +0400 +++ missing 2008-05-24 10:53:30.0 +0400 @@ -27,5 +27,5 @@ # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. - +# May 2008, ineiev: changed to build binutils-2.18 if test $# -eq 0; then echo 1>&2 "Try \`$0 --help' for more information" @@ -46,19 +46,4 @@ case "$1" in ---run) - # Try to run requested program, and just exit if it succeeds. - run= - shift - "$@" && exit 0 - # Exit code 63 means version mismatch. This often happens - # when the user try to use an ancient version of a tool on - # a file that requires a minimum version. In this case we - # we should proceed has if the program had been absent, or - # if --run hadn't been passed. - if test $? = 63; then -run=: -msg="probably too old" - fi - ;; -h|--h|--he|--hel|--help) @@ -101,7 +86,23 @@ exit 1 ;; +*) + # Try to run requested program, and just exit if it succeeds. + run= + if test $1 = "--run"; then +shift + fi + "$@" && exit 0 + # Exit code 63 means version mismatch. This often happens + # when the user try to use an ancient version of a tool on + # a file that requires a minimum version. In this case we + # we should proceed has if the program had been absent, or + # if --run hadn't been passed. + if test $? = 63; then +run=: +msg="probably too old" + fi + ;; esac - # Now exit if we have it, but it failed. Also exit now if we # don't have it and --version was passed (most likely to detect (the previous line is the last line of the patch) I believe this problem has been fixed in CVS already. Hope this helps, Ineiev ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
