[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-10 12:43 --- Created an attachment (id=17613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17613action=view) rewrite of dispatch table installation I agree with the approach you describe, in that we need a look-a-side buffer for the dispatch table to send messages during +initialize and install the dtable after +initialize returns. I was not comfortable with the patch because: /* Assumes that __objc_runtime_mutex is locked down. * If receiver is not null, it is the object whos supercalss must be * initialised if the superclass of the one we are installing the * dispatch table for is not already installed. */ __objc_begin_install_dispatch_table_for_class (Class class, Class receiver) I still have a hard time groking what was intended with the receiver. It all seems very intertwined and I think there is a more straight forward way to implement this. Also, with this patch get_imp fails on class methods. (get_imp also has the nasty effect of installing the dispatch table without calling +initialize and the same goes for __objc_responds_to). I'm not to fond of introducing InitializingList as special type. I think should be fine with using the existing hash map tables for this. I don't think we really need to introduce a new type. Do you really think that method dispatch for partially installed dispatch tables is performance critical? Well... after all this complaining, let's get to something more constructive :-). I've attached a patch (including some test cases which still need to be augmented) that I'd like to propose for a reimplementation originally based on your code. I hope I've added enough comments and asserts to insure the assumptions and prerequisites are met. For the final submission I'll remove some of the asserts. It combines __objc_install_dispatch_table_for_class and __objc_init_install_dtable into: /* This function is called by: objc_msg_lookup, get_imp and __objc_responds_to (and the dispatch table installation functions themselves) to install a dispatch table for a class. If CLS is a class, it installs instance methods. If CLS is a meta class, it installs class methods. In either case +initialize is invoked for the corresponding class. The implementation must insure that the dispatch table is not installed until +initialize completes. Otherwise it opens a potential race since the installation of the dispatch table is used as gate in regular method dispatch and we need to guarantee that +initialize is the first method invoked an that no other thread my dispatch messages to the class before +initialize completes. */ static void __objc_install_dtable_for_class (Class cls) Which implements your suggestion with the following helper functions: static void __objc_prepare_dtable_for_class (Class cls); - builds the dispatch table and stores it in a look-a-side buffer (I used the hash tables instead of a custom type). static struct sarray *__objc_prepared_dtable_for_class (Class cls); - access the prepared table: this is used to identify whether the dispatch table is currently being installed (akin to the __objc_is_initializing_dispatch_table of the proposed patch) and is also used for subclasses that may be +initialized during the +initialize of the super class (i.e. class clusters when NSString's +initialize invokes GSString methods an need to copy NSString's dtable. static void __objc_install_prepared_dtable_for_class (Class cls); - static IMP __objc_get_prepared_imp (Class cls,SEL sel); Could you please have a look and let me know what you think? I'm still going to write some more test, checking the class cluster behavior mentioned above and I'll need some tests wrt to categories. So this is not final but it should address the main issue and the get_imp/__objc_responds_to issue. Cheers, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 12:44:38 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug objc/29200] %s substituted with methods/selectors can't be properly translated
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-09 21:08 --- Subject: Bug 29200 Author: ayers Date: Thu Apr 9 21:08:18 2009 New Revision: 145857 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145857 Log: gcc/ 2009-04-09 David Ayers ay...@fsfe.org PR objc/29200 * objc/objc-act.c (warn_with_method): Remove helper function. (check_duplicates): Call warning and inform directly. (really_start_method): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/objc/objc-act.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug objc/29200] %s substituted with methods/selectors can't be properly translated
--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-09 21:15 --- Fixed in 4.5. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug objc/27377] [4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #12 from ayers at gcc dot gnu dot org 2009-04-08 12:03 --- Since the branch still isn't frozen, I've finally committed this simple fix on the release branch also. Regression fixed... PR closed. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.0 |4.0.0 4.3.4 4.4.0 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug objc/27377] [4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #11 from ayers at gcc dot gnu dot org 2009-04-08 11:59 --- Subject: Bug 27377 Author: ayers Date: Wed Apr 8 11:59:36 2009 New Revision: 145718 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145718 Log: gcc/ 2009-04-08 David Ayers ay...@fsfe.org PR objc/27377 * c-typeck.c (build_conditional_expr): Emit ObjC warnings by calling objc_compare_types and surpress warnings about incompatible C pointers that are compatible ObjC pointers. gcc/testsuite/ 2009-04-02 David Ayers ay...@fsfe.org PR objc/27377 * objc.dg/conditional-1.m: New tests. Added: branches/gcc-4_4-branch/gcc/testsuite/objc.dg/conditional-1.m Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/c-typeck.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug bootstrap/39659] New: [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc
... /bin/sh ../libtool --tag CXX --mode=compile /home/ayers/gcc/trunk/build/./gcc/xgcc -shared-libgcc -B/home/ayers/gcc/trunk/build/./gcc -nostdinc++ -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include -I/home/ayers/gcc/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -D_GNU_SOURCE-std=gnu++0x -c ../../../../libstdc++-v3/src/functexcept.cc libtool: compile: /home/ayers/gcc/trunk/build/./gcc/xgcc -shared-libgcc -B/home/ayers/gcc/trunk/build/./gcc -nostdinc++ -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include -I/home/ayers/gcc/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -D_GNU_SOURCE -std=gnu++0x -c ../../../../libstdc++-v3/src/functexcept.cc -fPIC -DPIC -o .libs/functexcept.o ../../../../libstdc++-v3/src/functexcept.cc: In function 'void std::__throw_logic_error(const char*)': ../../../../libstdc++-v3/src/functexcept.cc:65: error: region 6 may contain throw and is contained in region that may not Eh tree: 8 must_not_throw also known as:4, 5 6 allowed_exceptions tree_label:L3filter :0 types: 1 cleanup tree_label:L9 7 allowed_exceptions tree_label:L7filter :0 types: 2 cleanup tree_label:L2 3 cleanup tree_label:L0 ../../../../libstdc++-v3/src/functexcept.cc:65: internal compiler error: verify_eh_tree failed configured with: ../configure --enable-languages=obj-c++ --enable-version-specific-runtime-libs --program-suffix=-trunk PS: I claimed ice-on-valid-code as I assume that libstdc++v3 contains valid code here even though that's not something can really confirm... there doesn't seem to be an unadorned ICE keyword. PPS: I still need to figure out how create the preprocessed source during bootstrap... and I'll try to figure out when this showed up. -- Summary: [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build, EH Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ayers at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug bootstrap/39659] [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc
--- Comment #1 from ayers at gcc dot gnu dot org 2009-04-06 09:04 --- Possibly related: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39610 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-06 10:06 --- The patch fixes the build... a new bootstrap is in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #5 from ayers at gcc dot gnu dot org 2009-04-06 11:07 --- Bootstrap completed successfully, thanks for the fast patch! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #7 from ayers at gcc dot gnu dot org 2009-04-06 12:29 --- Fixed. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #9 from ayers at gcc dot gnu dot org 2009-04-06 21:22 --- I'm sorry, I'm simply not familiar with cygwin/mingw environments and cross builds. But I'm surprised that --enable-shared doesn't work. Is that a native build? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #11 from ayers at gcc dot gnu dot org 2009-04-06 21:59 --- With 'native' I meant mingw := build=host=target so no... it's not native in the sense that I was talking about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug objc/27377] [4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #10 from ayers at gcc dot gnu dot org 2009-04-02 12:41 --- Subject: Bug 27377 Author: ayers Date: Thu Apr 2 12:40:48 2009 New Revision: 145446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145446 Log: gcc/ 2009-03-29 David Ayers ay...@fsfe.org PR objc/27377 * c-typeck.c (build_conditional_expr): Emit ObjC warnings by calling objc_compare_types and surpress warnings about incompatible C pointers that are compatible ObjC pointers. gcc/testsuite/ 2009-03-29 David Ayers ay...@fsfe.org PR objc/27377 * objc.dg/conditional-1.m: New tests. Added: branches/gcc-4_3-branch/gcc/testsuite/objc.dg/conditional-1.m Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-typeck.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug objc/18456] [4.3/4.4/4.5 Regression] ICE compiling Objective C code with protocol-qualified objects
--- Comment #10 from ayers at gcc dot gnu dot org 2009-04-02 21:46 --- Subject: Bug 18456 Author: ayers Date: Thu Apr 2 21:46:00 2009 New Revision: 145478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145478 Log: 2009-04-02 David Ayers ay...@fsfe.org PR objc/18456 * objc.dg/bad-receiver-type-2.m: New test contributed by Alexander Mamberg. Added: trunk/gcc/testsuite/objc.dg/bad-receiver-type-2.m Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug objc/18456] [4.3/4.4/4.5 Regression] ICE compiling Objective C code with protocol-qualified objects
--- Comment #11 from ayers at gcc dot gnu dot org 2009-04-02 21:49 --- Subject: Bug 18456 Author: ayers Date: Thu Apr 2 21:49:37 2009 New Revision: 145479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145479 Log: 2009-04-02 David Ayers ay...@fsfe.org PR objc/18456 * objc.dg/bad-receiver-type-2.m: New test contributed by Alexander Mamberg. Added: branches/gcc-4_4-branch/gcc/testsuite/objc.dg/bad-receiver-type-2.m Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug objc/18456] [4.3/4.4/4.5 Regression] ICE compiling Objective C code with protocol-qualified objects
--- Comment #12 from ayers at gcc dot gnu dot org 2009-04-02 21:51 --- Subject: Bug 18456 Author: ayers Date: Thu Apr 2 21:51:26 2009 New Revision: 145480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145480 Log: 2009-04-02 David Ayers ay...@fsfe.org PR objc/18456 * objc.dg/bad-receiver-type-2.m: New test contributed by Alexander Mamberg. Added: branches/gcc-4_3-branch/gcc/testsuite/objc.dg/bad-receiver-type-2.m Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug objc/18456] [4.3/4.4/4.5 Regression] ICE compiling Objective C code with protocol-qualified objects
--- Comment #13 from ayers at gcc dot gnu dot org 2009-04-02 21:58 --- The test case which would trigger the ICE have now been committed to all active branches. The more specific test case wrt protocols and typedefs will be committed once an issue wrt a bogus warning has been addressed. Yet that's a separate diagnostics issue, which will only be addressed on the trunk with a separate patch. I'm closing this regression. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug objc/29200] %s substituted with methods/selectors can't be properly translated
--- Comment #2 from ayers at gcc dot gnu dot org 2009-04-03 00:31 --- Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00223.html -- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-25 04:31:11 |2009-04-03 00:31:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug objc/18456] [4.3/4.4/4.5 Regression] ICE compiling Objective C code with protocol-qualified objects
--- Comment #9 from ayers at gcc dot gnu dot org 2009-03-31 21:08 --- The ICE is fixed in trunk (4.5), 4.4 and 4.3.3 The original test case still produces a bogus warning. Posted an RFA for the second test case here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01826.html I'll close this once that second tests have been installed, since the ICE is fixed and the bogus warning is a different issue. -- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to work||4.3.3 4.4.0 4.5.0 Last reconfirmed|2006-02-01 04:40:40 |2009-03-31 21:08:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug objc/23709] [4.3/4.4/4.5 Regression] error recovery is not smart enough
--- Comment #8 from ayers at gcc dot gnu dot org 2009-03-31 21:29 --- Hi Andrew, will you have time to look at this? -- ayers at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 4.4.0 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23709
[Bug objc/25965] [4.3/4.4/4.5 Regression] Allows duplicate member names in objc subclasses
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-31 21:46 --- Hi Andrew, are you still interested in the patch that caused this or is it fine if we simply try to fix this? -- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to fail||4.3.3 4.4.0 4.5.0 Last reconfirmed|2006-01-26 21:30:43 |2009-03-31 21:46:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25965
[Bug objc/28050] [4.3/4.4/4.5 regression] ICE on invalid initializer
--- Comment #5 from ayers at gcc dot gnu dot org 2009-03-31 22:22 --- Technically this doesn't ICE anymore, yet I've been told that an confused by earlier errors, bailing out is equivalent... so I'll reconfirm this. The patch from looks sane to me. Has there been an official RFA for this? I could post it together with the test case if you like? -- ayers at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 4.4.0 4.5.0 Last reconfirmed|2006-10-21 21:32:55 |2009-03-31 22:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #8 from ayers at gcc dot gnu dot org 2009-03-29 08:09 --- Subject: Bug 27377 Author: ayers Date: Sun Mar 29 08:09:44 2009 New Revision: 145225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145225 Log: gcc/ 2009-03-00 David Ayers ay...@fsfe.org PR objc/27377 * c-typeck.c (build_conditional_expr): Emit ObjC warnings by calling objc_compare_types and surpress warnings about incompatible C pointers that are compatible ObjC pointers. testsuite/ 2009-03-00 David Ayers ay...@fsfe.org PR objc/27377 * objc.dg/conditional-1.m: New tests. Added: trunk/gcc/testsuite/objc.dg/conditional-1.m Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #7 from ayers at gcc dot gnu dot org 2009-03-19 07:07 --- For the record: the official RFA was posted here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00666.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #2 from ayers at gcc dot gnu dot org 2009-03-16 07:27 --- So the situation seems to be: - libobjc is a static library. - libfoo is a dll statically linked against libobjc. - test is program which is linked both against libfoo and libobjc. I'm guessing here since I have no experience mingw and with linking libobjc statically, but I could imagine that you may have two copies of libobjc in your executable each with it's own set of runtime structures, which may cause confusion. Is there any reason why libobjc isn't dynamically linked if you going to use DLL's? Note I'll still need to build a mingw compiler and look into the auto-import warning and I'm not sure when I'll get around to it, so I haven't assigned the bug yet in case someone else can easily test it. Cheers, David -- ayers at gcc dot gnu dot org changed: What|Removed |Added CC||ayers at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #4 from ayers at gcc dot gnu dot org 2009-03-16 11:41 --- Well, consider me a GNUstep guy yet I'm definitely not a GNUstep on MinGW32 guy. (Or anything on MinGW32... which is why this a bit difficult, yet I'm trying to help maintain libobjc so I'll see what I can do.) Could you please add a link to that discussion? It seems that I missed it. I've found a few mingw32 discussions searching the archive but nothing recent wrt static linking. In the meantime I'm learning how to setup a cross tool chain... please be patient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-16 23:51 --- I've played a bit with creating a trivial static library and linking into an dynamic library and into an executable. After tweaking back and forth it seems that at least on GNU/Linux the static version linked into the executable actually replaces the version that was linked into the dynamic library... not sure what would happen if the version linked in last doesn't satisfy all the requirements needed by the dynamic library. All very intriguing , yet I believe it has nothing to do with your issue. Since I wasn't able to get a cross tool chain running (and www.mingw.org doesn't seem to support that with the current gcc versions) I went ahead and updated an old Windows VM, installed all kinds of updates... and then installed MinGW/MSYS natively. First I reproduced you issue successfully and then went about installing GNUstep. Note that GNUstep's MinGW HOWTO explicitly states: It's a good idea to remove the libobjc.a and libobjc.la and include/objc headers that come with gcc (gcc -v for location) so that they are not accidentally found instead of the libobjc DLL that you will compile below. ... After installing the GNUstep packages, I was able to build and execute applications. Now GNUstep uses it's own build environment (gnustep-make) to hide all the fancy stuff that needs to be done on windows. I was hoping to see something with messages=yes to give me an indication of what you need to do. Yet I had no luck in identifying anything interesting. Well except that GNUstep is using a shared libobjc. I'm going to throw in the towel here, but I don't believe your issue has to do with libobjc. I think your missing some flag or extra processing that gnustep-make might do for you dll or the program. But I also believe that statically linking (potentially different versions) of libobjc into different modules is error prone. I guess it would be OK, if you only have a single executable, but the constellation of the dll linking one version and the executable potentially linking another scares me... even if that itself is most likely not your issue either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug objc/22474] Objc produces mis-match (non compatible) types in EQ_EXPR
--- Comment #3 from ayers at gcc dot gnu dot org 2009-03-15 07:38 --- Confirmed that this is fixed in 4.3 and the trunk. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22474
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |ayers at gcc dot gnu dot org |org | Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #9 from ayers at gcc dot gnu dot org 2009-03-14 17:05 --- Fixed for 4.4.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug objc/27377] [4.2/4.3/4.4 Regression] false compiler warnings generated in Objective-C code
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-14 17:11 --- Created an attachment (id=17465) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17465action=view) patch for build_conditional_expr This patch for build_conditional_expr is modeled after build_binary_op in that it skips the diagnostic if the objc_compare_types verifies that the types are compatible. If the maintainers wish, I can follow up with a little optimization for the C front end for both build_conditional_expr and build_binary_op in that objc_compare_types will only be called for c_dialect_objc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377
[Bug libobjc/27466] RFE: Support for libobjc equivalent of std::set_unexpected
--- Comment #8 from ayers at gcc dot gnu dot org 2009-03-12 22:28 --- Subject: Bug 27466 Author: ayers Date: Thu Mar 12 22:28:15 2009 New Revision: 144826 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144826 Log: libobjc/ 2009-03-12 Richard Frith-Macdonald r...@gnu.org David Ayers ay...@fsfe.org PR libobjc/27466 * objc/objc-api.h (_objc_unexpected_exception): Declare new hook. Update copyright dates. * exception.c (objc_exception_throw): Use hook. Update copyright dates. * libobjc.def (_objc_unexpected_exception): Export hook. Update copyright dates. gcc/testsuite/ 2009-03-12 David Ayers ay...@fsfe.org PR libobjc/27466 * objc/execute/exceptions/handler-1.m. New test. Added: trunk/gcc/testsuite/objc/execute/exceptions/handler-1.m Modified: trunk/gcc/testsuite/ChangeLog trunk/libobjc/ChangeLog trunk/libobjc/exception.c trunk/libobjc/libobjc.def trunk/libobjc/objc/objc-api.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug bootstrap/28072] [4.2 Regression] target-boehm-gc is being build for targets that do not support it
--- Comment #1 from ayers at gcc dot gnu dot org 2006-06-20 08:45 --- Subject: Bug 28072 Author: ayers Date: Tue Jun 20 08:45:08 2006 New Revision: 114808 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114808 Log: 2006-06-20 David Ayers [EMAIL PROTECTED] PR bootstrap/28072 * configure.in: Add target-boehm-gc to noconfigdirs depending on whether target-libjava is being configured instead of whether the java front end is enabled. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug bootstrap/28072] [4.2 Regression] target-boehm-gc is being build for targets that do not support it
--- Comment #2 from ayers at gcc dot gnu dot org 2006-06-20 08:54 --- Fixed for 4.2.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug bootstrap/28072] New: [4.2 Regression] target-boehm-gc is being build for targets that do not support it
This regression was cause by the patches allowing Boehm-GC to be build with --enable-objc-gc. The problem is that instead of testing whether java is part of enabled languages (as java is a default langauge and the front end is build independent of the runtime), the new configure test should test whether the java runtime (target-libjava) is being build. This not only affects sh-elf but any target that fails to build target-boehmgc. -- Summary: [4.2 Regression] target-boehm-gc is being build for targets that do not support it Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ayers at gcc dot gnu dot org GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug bootstrap/28072] [4.2 Regression] target-boehm-gc is being build for targets that do not support it
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-17 09:52:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28072
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #8 from ayers at gcc dot gnu dot org 2006-06-12 06:58 ---
Subject: Bug 27963
Author: ayers
Date: Mon Jun 12 06:58:27 2006
New Revision: 114563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114563
Log:
2006-06-12 David Ayers [EMAIL PROTECTED]
PR bootstrap/27963
PR target/19970
* configure.in: Remove target-boehm-gc from noconfigdirs where
${libgcj} is specified.
* configure: Regenerate.
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.in
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug target/19970] Java Disabled for MinGW
--- Comment #5 from ayers at gcc dot gnu dot org 2006-06-12 06:58 ---
Subject: Bug 19970
Author: ayers
Date: Mon Jun 12 06:58:27 2006
New Revision: 114563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114563
Log:
2006-06-12 David Ayers [EMAIL PROTECTED]
PR bootstrap/27963
PR target/19970
* configure.in: Remove target-boehm-gc from noconfigdirs where
${libgcj} is specified.
* configure: Regenerate.
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.in
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #9 from ayers at gcc dot gnu dot org 2006-06-12 07:04 --- Fixed for 4.2.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-09 07:57:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #6 from ayers at gcc dot gnu dot org 2006-06-09 08:01 --- Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00410.html and waiting for approval. -- ayers at gcc dot gnu dot org changed: What|Removed |Added CC|d dot ayers at inode dot at | Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #4 from ayers at gcc dot gnu dot org 2006-06-08 20:18 --- Hello, I followed the advice given here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00886.html I believe noconfigdir is supposed to mean not supported so in this case the correct patch would be to remove tartget-boehm-gc if in fact it is supported by the platform, as we will later remove it again if it wasn't requested by libobjc and not needed by java. If I get a get a list of targets for which I should re-enable target-boehm-gc (and possibly pre approval) I can certainly come up with a patch (it's just a matter of removing target-boehm-gc from the appropriate noconfigdir entry). Cheers, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #7 from ayers at gcc dot gnu dot org 2006-06-06 16:05 ---
Subject: Bug 13946
Author: ayers
Date: Tue Jun 6 16:05:47 2006
New Revision: 114435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114435
Log:
2006-06-06 David Ayers [EMAIL PROTECTED]
PR libobjc/13946
* Makefile.def: Add dependencies for libobjc which boehm-gc.
* Makefile.in: Regenerate.
* configure.in: Add --enable-objc-gc at toplevel and have it
enable boehm-gc for Objective-C.
Remove target-boehm-gc from libgcj.
Add target-boehm-gc to target_libraries.
Add target-boehm-gc to noconfigdirs where ${libgcj}
is specified.
Assert that boehm-gc is supported when requested for Objective-C.
Only build boehm-gc if needed either for Java or Objective-C.
* configure: Regenerate.
Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/configure
trunk/configure.in
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #8 from ayers at gcc dot gnu dot org 2006-06-06 16:57 --- Fixed for 4.2.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #4 from ayers at gcc dot gnu dot org 2006-01-24 21:57 --- Subject: Bug 13946 Author: ayers Date: Tue Jan 24 21:57:22 2006 New Revision: 110182 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110182 Log: 2006-01-24 David Ayers [EMAIL PROTECTED] PR libobjc/13946 * configure.ac: Add include directives for --enable-objc-gc. * Makefile.in: Ditto. * configure: Regenerate. * gc.c (__objc_class_structure_encoding): Increment the used bytes instead of the local pointer to them. Modified: trunk/libobjc/ChangeLog trunk/libobjc/Makefile.in trunk/libobjc/configure trunk/libobjc/configure.ac trunk/libobjc/gc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #5 from ayers at gcc dot gnu dot org 2006-01-24 22:00 --- Subject: Bug 13946 Author: ayers Date: Tue Jan 24 22:00:26 2006 New Revision: 110183 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110183 Log: 2006-01-24 David Ayers [EMAIL PROTECTED] PR libobjc/13946 * include/gc.h: Fix prototype declarations for bootstrap. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/include/gc.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug libobjc/9751] malloc of strlen, not strlen+1
--- Comment #6 from ayers at gcc dot gnu dot org 2006-01-24 23:37 --- Subject: Bug 9751 Author: ayers Date: Tue Jan 24 23:37:24 2006 New Revision: 110187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110187 Log: 2006-01-24 David Ayers [EMAIL PROTECTED] PR libobjc/9751 * gc.c (class_ivar_set_gcinvisible): Replace strncpy with memcpy and insure the new strings are '\0' termintated. Modified: trunk/libobjc/ChangeLog trunk/libobjc/gc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9751
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #3 from ayers at gcc dot gnu dot org 2006-01-23 13:03 --- I've posted some patches for this: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01532.html http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01533.html http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01534.html -- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- Comment #3 from ayers at gcc dot gnu dot org 2005-12-15 16:46 --- Subject: Bug 14382 Author: ayers Date: Thu Dec 15 16:46:17 2005 New Revision: 108584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108584 Log: 2005-12-15 David Ayers [EMAIL PROTECTED] PR libobjc/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: trunk/libobjc/ChangeLog trunk/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- Comment #4 from ayers at gcc dot gnu dot org 2005-12-15 17:23 --- Subject: Bug 14382 Author: ayers Date: Thu Dec 15 17:23:10 2005 New Revision: 108587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108587 Log: 2005-12-15 David Ayers [EMAIL PROTECTED] PR libobjc/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: branches/gcc-4_0-branch/libobjc/ChangeLog branches/gcc-4_0-branch/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- Comment #5 from ayers at gcc dot gnu dot org 2005-12-15 18:01 --- Subject: Bug 14382 Author: ayers Date: Thu Dec 15 18:01:17 2005 New Revision: 108588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108588 Log: 2005-12-15 David Ayers [EMAIL PROTECTED] PR libobjc/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: branches/gcc-4_1-branch/libobjc/ChangeLog branches/gcc-4_1-branch/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug libobjc/14382] [libobjc] Calling +initialize on a per category basis
--- Comment #6 from ayers at gcc dot gnu dot org 2005-12-15 18:24 --- Subject: Bug 14382 Author: ayers Date: Thu Dec 15 18:23:40 2005 New Revision: 108589 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108589 Log: 2005-12-15 David Ayers [EMAIL PROTECTED] PR libobjc/14382 * README (+load,+initialize): Fix documentation to reflect intended and implemented semantics for +load and +initialize. Modified: branches/gcc-3_4-branch/libobjc/ChangeLog branches/gcc-3_4-branch/libobjc/README -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14382
[Bug libobjc/19024] name collisions libobjc/libmysqlclient
--- Comment #9 from ayers at gcc dot gnu dot org 2005-11-20 12:49 --- Subject: Bug 19024 Author: ayers Date: Sun Nov 20 12:49:41 2005 New Revision: 107251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107251 Log: 2005-11-20 David Ayers [EMAIL PROTECTED] PR libobjc/19024 * objc/hash.h: Remove deprecated hash API. * hash_compat.c: Remove. * Makefile.in: Remove reference to hash_compat.c. * configure.ac (VERSION): Bump library version to 2:0:0. * configure: Regenerate. Removed: trunk/libobjc/hash_compat.c Modified: trunk/libobjc/ChangeLog trunk/libobjc/Makefile.in trunk/libobjc/configure trunk/libobjc/configure.ac trunk/libobjc/objc/hash.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19024
