Message ID | 4C6B6392.8080108@gcc.gnu.org |
---|---|
State | New |
Headers | show |
Hi Philip, On 18 Aug 2010, at 05:37, Philip Herron wrote: > Following up this thread on gcc-help: > http://gcc.gnu.org/ml/gcc-help/2010-08/msg00087.html thanks for looking at this - ObjC* needs all the developers it can get :) > The compiler driver code i added for both is a vanilla driver, which > could fail though, since i don't tell anything to explicitly link > their > respective runtime libraries shouldn't be necessary to do anything explicit for a correctly installed compiler. .. but ... you will still need to add the relevant '-B's & '-L's if you want to do uninstalled testing with the driver(s) named specifically -- the testsuite already handles the addition of -lxxx for objc/cpp when using the xgcc driver. There is a 'gotcha' with headers that will break testing of darwin if you are not careful -- look at the objc-*.exp in gcc/testsuite/libs - they determine which runtime is in force and make sure to adjust the header paths accordingly. [Darwin must find the system's installed ObjC headers when testing with -fnext-runtime, since the NeXT runtime is part of the system, not part of gcc.]. > though i would doubt the objc front-end i > just tested would generate working code without doing that so i may be > fine as is. ObjC++ also needs to add lstdc++ (if you didn't so far, I've not read the patch yet). > I am having problems with the objcp one so far it doesn't seem to get > installed so i need to look into this though i would like to get a > review on the patch as it stands so as i know i am on the right track. I'll try and take a look later (although I'm not an approver of any sort, I should add). cheers, Iain
Hi Philip, On 18 Aug 2010, at 05:37, Philip Herron wrote: > I added a objc and objcp compiler drivers, the objc one works so far > as > much as i can tell i tested a hello world program with gccobjc hello.m > and the resulting a.out worked. not quite sure how you achieved this, since -lobjc is not added AFAICT ... does this work? #include <objc/Object.h> @interface Adder : Object - (int) addone: (int)num; @end @implementation Adder - (int) addone: (int)num { return num+1 ; } @end #include <stdio.h> int main () { int five; Adder *obj = [Adder new]; five = [obj addone: 4 ]; printf("no %d\n", five); return five; } > The compiler driver code i added for both is a vanilla driver, right, and now you have to populate lang_specific_driver () [ on the assumption that what is required cannot be achieved with specs, which is consistent with the other drivers] If I was doing this I'd steal (& modify) the options parser from gfortran and use the lang_specific_driver from g++ as a template for dealing with recognizing the case of PCH. the steps, AFAIU are: 1/ parse the provided args to detect (a) whether this is a session involving linking (b) any libs the user has provided. (c) the need for a mathlib (on systems that use one) (d) permutations of libgcc (e) ** possibly, although not currently supported, the need for static linkage. 2/ if _not_ linking make sure that no linker commands get into the output - because this messes up PCH (actually, last time I checked, g++ does not work with PCH if you put -static-libstdc++ or any -Wl,... on the cl). 3/ re-write the args with whatever additions and re-ordering of libs is needed, .. (in particular, for example, making sure that lm appears after lstdc++ ) and wrapping of non-native-language filenames (e.g. compiling foo.c as if it were foo.m), 4/ tell the caller what you've done. > I am having problems with the objcp one so far it doesn't seem to get > installed just an unwanted .PHONY, I suspect. ------ FWIW (at the risk of starting a debate.... ) : I personally would prefer (in descending order of preference); objc ... gcc-objc (I don't think objc clashes with anything) obj-c++ ... obj-g++ ... objc++ ... objg++ ... gcc-obj-c++ ... cheers, Iain
On Wed, 18 Aug 2010, IainS wrote: > If I was doing this I'd steal (& modify) the options parser from gfortran and > use the lang_specific_driver from g++ as a template for dealing with > recognizing the case of PCH. Please refactor into shared code instead of copying from one place to another with random changes. For Obj-C++ you probably want to share all the existing g++ driver code. I'm in the process of debugging a patch that moves lang_specific_driver to working with cl_decoded_option structures. Lots of oddities in the existing lang_specific_driver code have shown up in the process and I've no real idea whether some of them have good reasons behind them. For example, why do some drivers but not others have special treatment of 0-character and 1-character operands (not always limited to "-" but sometimes including other 1-character operands) different from how they handle other non-option operands? The comment /* We don't do this anymore, since we don't get them with minus signs on them. */ that has also clearly been copied from one place to another doesn't make any sense to me.
On Aug 17, 2010, at 9:37 PM, Philip Herron wrote: > I added a objc and objcp compiler drivers, First, formalities... Do you have your paper work for gcc done? If not, if you want to contribute larger chunks, it is required. > the objc one works so far as much as i can tell i tested a hello world program with gccobjc hello.m and the resulting a.out worked. The likelihood of getting it wrong should be low. I glanced at the patch, looks mostly fine to me. > The compiler driver code i added for both is a vanilla driver, which > could fail though, since i don't tell anything to explicitly link their > respective runtime libraries though i would doubt the objc front-end i > just tested would generate working code without doing that so i may be > fine as is. Mostly fine as is, but, we'd solicit the next step, which would be adding the -l flags as appropriate, and defaulting to objc for .c files... As the C++ driver comes up, defaulting it to obj-c++ for the normal C++ extensions would be nice. After that, well, can't recall anything that would need doing. If anyone else can think of something, let them speak up! > I am having problems with the objcp one so far it doesn't seem to get installed so i need to look into this though i would like to get a review on the patch as it stands so as i know i am on the right track. If you exactly copy the g++ driver, you should be able to copy is semantics... That'd be the first step. I didn't diff between the two to look at the differences... [ pause ] Ok, I looked at some of the differences... In general, you want to get rid of the differences... For example, I didn't see a use of program_transform_name. Copy exactly, and only change the parts you are certain are wrong or don't apply and you'll have an easier time. The other thing I'd change are the names, gccobjcp, mouthful. Please use objc++ and objc as the driver names. The long form of the drivers would be gobjc and gobjc++. For ++less systems, following what they do for those system would be best.
On 18 August 2010 18:14, Mike Stump <mikestump@comcast.net> wrote: > On Aug 17, 2010, at 9:37 PM, Philip Herron wrote: >> I added a objc and objcp compiler drivers, > > First, formalities... Do you have your paper work for gcc done? If not, if you want to contribute larger chunks, it is required. > >> the objc one works so far as much as i can tell i tested a hello world program with gccobjc hello.m and the resulting a.out worked. > > The likelihood of getting it wrong should be low. I glanced at the patch, looks mostly fine to me. > >> The compiler driver code i added for both is a vanilla driver, which >> could fail though, since i don't tell anything to explicitly link their >> respective runtime libraries though i would doubt the objc front-end i >> just tested would generate working code without doing that so i may be >> fine as is. > > Mostly fine as is, but, we'd solicit the next step, which would be adding the -l flags as appropriate, and defaulting to objc for .c files... As the C++ driver comes up, defaulting it to obj-c++ for the normal C++ extensions would be nice. After that, well, can't recall anything that would need doing. If anyone else can think of something, let them speak up! > >> I am having problems with the objcp one so far it doesn't seem to get installed so i need to look into this though i would like to get a review on the patch as it stands so as i know i am on the right track. > > If you exactly copy the g++ driver, you should be able to copy is semantics... That'd be the first step. I didn't diff between the two to look at the differences... [ pause ] Ok, I looked at some of the differences... In general, you want to get rid of the differences... For example, I didn't see a use of program_transform_name. Copy exactly, and only change the parts you are certain are wrong or don't apply and you'll have an easier time. > > The other thing I'd change are the names, gccobjcp, mouthful. Please use objc++ and objc as the driver names. The long form of the drivers would be gobjc and gobjc++. For ++less systems, following what they do for those system would be best. Thanks for all the pointers you guys gave, when i started i wasnt quite sure what would work or not! And yes i do have gnu copy approval. I will endeavour to clean this up and do the changes in driver names and let you guys know how i get on soon, i couldn't work on this today had to help a friend move house but will work on this tomorrow :) That test you told me to try didnt work since i dont link in the objc runtime library: redbrain@omicron:~ $ gccobjc -fdump-tree-gimple test.m /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld: /tmp/cc95Hin0.o: in function main:test.m(.text+0x1d): error: undefined reference to 'objc_get_class' /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld: /tmp/cc95Hin0.o: in function main:test.m(.text+0x2f): error: undefined reference to 'objc_msg_lookup' /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld: /tmp/cc95Hin0.o: in function main:test.m(.text+0x54): error: undefined reference to 'objc_msg_lookup' /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld: /tmp/cc95Hin0.o: in function __objc_gnu_init:test.m(.text+0x9d): error: undefined reference to '__objc_exec_class' /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/bin/ld: /tmp/cc95Hin0.o: in function __objc_class_ref_Object:test.m(.data+0x100): error: undefined reference to '__objc_class_name_Object' collect2: ld returned 1 exit status But i can do that now the program which did work for me was: #import <stdio.h> int main( int argc, const char *argv[] ) { printf( "hello world\n" ); return 0; } But i guess since all what's going on there is a c program with some different c-preprocessor statements so no extra objc features were actually being used. --Phil
Hey all, I started to work on this again for a little bit, i followed the gcc/gfrotranspec.c compiler driver since its such a pristine driver its hard not to copy it. Though i would like a review since i am having problems with the Make-lang.in to install the driver not quite sure what i've done wrong, i am not great at writing make some pointers would be great, it says i need to look at $(COMPILERS) or such for the install hooks. --Phil
On Sat, 4 Sep 2010, Philip Herron wrote: > Hey all, > > I started to work on this again for a little bit, i followed the > gcc/gfrotranspec.c compiler driver since its such a pristine driver > its hard not to copy it. My previous comments still apply: copying code with random changes is bad and leads to gratuitous divergence as subsequent improvements don't get applied to all the copies, refactoring so that code can be shared is good. It may be possible to reduce the C, C++ and Fortran drivers to a single piece of shared code that takes a datastructure describing the libraries required by the respective languages; certainly, patches that increase code sharing and reduce the amount of ObjC-specific code needed for an ObjC-specific driver would be a much better start than going straight into writing that driver.
On 4 September 2010 01:14, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sat, 4 Sep 2010, Philip Herron wrote: > >> Hey all, >> >> I started to work on this again for a little bit, i followed the >> gcc/gfrotranspec.c compiler driver since its such a pristine driver >> its hard not to copy it. > > My previous comments still apply: copying code with random changes is bad > and leads to gratuitous divergence as subsequent improvements don't get > applied to all the copies, refactoring so that code can be shared is good. > It may be possible to reduce the C, C++ and Fortran drivers to a single > piece of shared code that takes a datastructure describing the libraries > required by the respective languages; certainly, patches that increase > code sharing and reduce the amount of ObjC-specific code needed for an > ObjC-specific driver would be a much better start than going straight into > writing that driver. > > -- > Joseph S. Myers > joseph@codesourcery.com > Then does it make sense for a compiler driver to be generated from some kind of a config, i agree i've always found the compiler drivers a frustrating thing, since for the most part all will do pretty similar things, most customizations would be add extra linker options i guess. I am not sure if that means we would have a build system to generate it from a bash script and add extra options to the config-lang.in to generate this or something. --Phil
On Sat, 4 Sep 2010, Philip Herron wrote: > Then does it make sense for a compiler driver to be generated from > some kind of a config, i agree i've always found the compiler drivers > a frustrating thing, since for the most part all will do pretty > similar things, most customizations would be add extra linker options > i guess. I am not sure if that means we would have a build system to > generate it from a bash script and add extra options to the > config-lang.in to generate this or something. I am suggesting something much simpler: incremental refactoring of the existing code, moving shared utility functions to gcc.c, so that in the end most drivers can call a shared function and pass a C structure to it. Not anything requiring generator programs. For example, you might adapt the Fortran functions such as append_arg to allocate space dynamically rather than hardcoding limits on the size of the new array of options based on the old one, move them to gcc.c with declarations in gcc.h and make all drivers use them. That could be one of the incremental patches. Subsequent ones might try to identify what is common about the logic to add language-specific libraries. There is an idea that we don't really want all these drivers at all - we want "gcc" to link in the right libraries automatically for whatever languages were used for the object files it is asked to link - which certainly requires those libraries to be described by suitable datastructures gcc.c can use.
On 4 September 2010 01:29, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Sat, 4 Sep 2010, Philip Herron wrote: > >> Then does it make sense for a compiler driver to be generated from >> some kind of a config, i agree i've always found the compiler drivers >> a frustrating thing, since for the most part all will do pretty >> similar things, most customizations would be add extra linker options >> i guess. I am not sure if that means we would have a build system to >> generate it from a bash script and add extra options to the >> config-lang.in to generate this or something. > > I am suggesting something much simpler: incremental refactoring of the > existing code, moving shared utility functions to gcc.c, so that in the > end most drivers can call a shared function and pass a C structure to it. > Not anything requiring generator programs. > > For example, you might adapt the Fortran functions such as append_arg to > allocate space dynamically rather than hardcoding limits on the size of > the new array of options based on the old one, move them to gcc.c with > declarations in gcc.h and make all drivers use them. That could be one of > the incremental patches. Subsequent ones might try to identify what is > common about the logic to add language-specific libraries. > > There is an idea that we don't really want all these drivers at all - we > want "gcc" to link in the right libraries automatically for whatever > languages were used for the object files it is asked to link - which > certainly requires those libraries to be described by suitable > datastructures gcc.c can use. > > -- > Joseph S. Myers > joseph@codesourcery.com > Ah ok i see what you mean now, thanks by the way. I'll play around with that now and see what happens and do it for the objc front-end first. --Phil
diff --git a/gcc/objc/Make-lang.in b/gcc/objc/Make-lang.in index 67644bb..645a809 100644 --- a/gcc/objc/Make-lang.in +++ b/gcc/objc/Make-lang.in @@ -36,13 +36,17 @@ # - the compiler proper (eg: cc1plus) # - define the names for selecting the language in LANGUAGES. -# -# Define the names for selecting Objective-C in LANGUAGES. -objc: cc1obj$(exeext) +OBJC_EXECS = objc # Tell GNU make to ignore these if they exist. .PHONY: objc +GCCOBJC_INSTALL_NAME := $(shell echo gccobjc|sed '$(program_transform_name)') +GCCOBJC_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gccobjc|sed '$(program_transform_name)') + +# Define the names for selecting Objective-C in LANGUAGES. +objc: gccobjc$(exeext) cc1obj$(exeext) + # Use maximal warnings for this front end. objc-warn = $(STRICT_WARN) @@ -80,9 +84,18 @@ objc/objc-act.o : objc/objc-act.c \ $(LANGHOOKS_DEF_H) $(HASHTAB_H) $(C_PRAGMA_H) gt-objc-objc-act.h \ $(GIMPLE_H) c-lang.h +objc-spec.o: $(srcdir)/objc/objc-spec.c $(CONFIG_H) $(SYSTEM_H) \ + coretypes.h $(DIAGNOSTIC_H) $(TREE_H) $(FLAGS_H) toplev.h langhooks.h $(TM_H) + $(CC) $(GPY_CFLAGS) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \ + $(INCLUDES) $(LDFLAGS) -c -o $@ $(srcdir)/objc/objc-spec.c + +GCCOBJC_D_OBJS = $(GCC_OBJS) objc-spec.o version.o prefix.o intl.o +gccobjc$(exeext): $(GCCOBJC_D_OBJS) $(EXTRA_GCC_OBJS) $(LIBDEPS) + $(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ + $(GCCOBJC_D_OBJS) $(EXTRA_GCC_OBJS) $(LIBS) + objc.srcextra: -# # Build hooks: objc.all.cross: @@ -99,6 +112,7 @@ objc.man: objc.srcinfo: objc.srcman: objc.install-plugin: +objc.install-man: objc.tags: force cd $(srcdir)/objc; etags -o TAGS.sub *.c *.h; \ @@ -106,16 +120,17 @@ objc.tags: force lang_checks += check-objc -# # Install hooks: -# cc1obj is installed elsewhere as part of $(COMPILERS). - -objc.install-common: +objc.install-common: installdirs + -rm -f $(DESTDIR)$(bindir)/$(GCCOBJC_INSTALL_NAME)$(exeext) + -$(INSTALL_PROGRAM) gccobjc$(exeext) $(DESTDIR)$(bindir)/$(GCCOBJC_INSTALL_NAME)$(exeext) + -chmod a+x $(DESTDIR)$(bindir)/$(GCCOBJC_INSTALL_NAME)$(exeext) -objc.install-man: +objc.install-plugin: objc.uninstall: -# + -rm -rf $(DESTDIR)/$(bindir)/$(GCCOBJC_INSTALL_NAME)$(exeext) + # Clean hooks: # A lot of the ancillary files are deleted by the main makefile. # We just have to delete files specific to us. @@ -129,7 +144,7 @@ objc.distclean: -rm -f objc/config.status objc/config.cache objc.maintainer-clean: -# + # Stage hooks: objc.stage1: stage1-start @@ -144,3 +159,5 @@ objc.stageprofile: stageprofile-start -mv objc/*$(objext) stageprofile/objc objc.stagefeedback: stagefeedback-start -mv objc/*$(objext) stagefeedback/objc + +config.status: objc/config-lang.in \ No newline at end of file diff --git a/gcc/objc/objc-spec.c b/gcc/objc/objc-spec.c new file mode 100644 index 0000000..8a44180 --- /dev/null +++ b/gcc/objc/objc-spec.c @@ -0,0 +1,38 @@ +/* This file is part of GCC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING3. If not see +<http://www.gnu.org/licenses/>. */ + +#include "config.h" +#include "system.h" +#include "gcc.h" + +#include "coretypes.h" +#include "tm.h" + +void lang_specific_driver( int *in_argc ATTRIBUTE_UNUSED, + const char *const **in_argv ATTRIBUTE_UNUSED, + int *in_added_libraries ATTRIBUTE_UNUSED ) +{ + return; +} + +/* Called before linking. Returns 0 on success and -1 on failure. */ +int lang_specific_pre_link( void ) +{ + return 0; +} + +/* Number of extra output files that lang_specific_pre_link may generate. */ +int lang_specific_extra_outfiles = 0; diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in index 22dc30f..64ef647 100644 --- a/gcc/objcp/Make-lang.in +++ b/gcc/objcp/Make-lang.in @@ -37,12 +37,16 @@ # - the compiler proper (eg: cc1plus) # - define the names for selecting the language in LANGUAGES. -# -# Define the names for selecting Objective-C++ in LANGUAGES. -obj-c++: cc1objplus$(exeext) +OBJC_EXECS = objc-c++ # Tell GNU make to ignore these if they exist. -.PHONY: obj-c++ +.PHONY: gccobjcp obj-c++ + +GCCOBJCP_INSTALL_NAME := $(shell echo gccobjcp|sed '$(program_transform_name)') +GCCOBJCP_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gccobjcp|sed '$(program_transform_name)') + +# Define the names for selecting Objective-C++ in LANGUAGES. +obj-c++: gccobjcp$(exeext) cc1objplus$(exeext) # Use maximal warnings for this front end. Also, make ObjC and C++ # headers accessible. @@ -90,9 +94,19 @@ objcp/objcp-act.o : objc/objc-act.c \ $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< \ $(OUTPUT_OPTION) +objcp-spec.o: $(srcdir)/objcp/objcp-spec.c $(CONFIG_H) $(SYSTEM_H) \ + coretypes.h $(DIAGNOSTIC_H) $(TREE_H) $(FLAGS_H) toplev.h langhooks.h $(TM_H) + $(CC) $(GPY_CFLAGS) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \ + $(INCLUDES) $(LDFLAGS) -c -o $@ $(srcdir)/objcp/objcp-spec.c + +GCCOBJCP_D_OBJS = $(GCC_OBJS) objcp-spec.o version.o prefix.o intl.o +gccobjcp$(exeext): $(GCCOBJCP_D_OBJS) $(EXTRA_GCC_OBJS) $(LIBDEPS) + $(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ + $(GCCOBJC_D_OBJS) $(EXTRA_GCC_OBJS) $(LIBS) + po-generated: -# + # Build hooks: obj-c++.all.cross: @@ -108,36 +122,41 @@ obj-c++.install-html: obj-c++.srcinfo: obj-c++.srcextra: obj-c++.man: -obj-c++.install-plugin: +obj-c++.install-man: obj-c++.tags: force - cd $(srcdir)/objcp; etags -o TAGS.sub *.y *.c *.h; \ + cd $(srcdir)/obj-c++p; etags -o TAGS.sub *.y *.c *.h; \ etags --include TAGS.sub --include ../TAGS.sub lang_checks += check-obj-c++ -# # Install hooks: # cc1objplus is installed elsewhere as part of $(COMPILERS). -obj-c++.install-common: +obj-c++.install-common: installdirs + -rm -f $(DESTDIR)$(bindir)/$(GCCOBJCP_INSTALL_NAME)$(exeext) + -$(INSTALL_PROGRAM) gccobjp$(exeext) $(DESTDIR)$(bindir)/$(GCCOBJCP_INSTALL_NAME)$(exeext) + -chmod a+x $(DESTDIR)$(bindir)/$(GCCOBJCP_INSTALL_NAME)$(exeext) -obj-c++.install-man: +obj-c++.install-plugin: obj-c++.uninstall: -# + -rm -rf $(DESTDIR)/$(bindir)/$(GCCOBJ-C++_INSTALL_NAME)$(exeext) + # Clean hooks: # A lot of the ancillary files are deleted by the main makefile. # We just have to delete files specific to us. obj-c++.mostlyclean: -rm -f objcp/*$(objext) -rm -f objcp/*$(coverageexts) + obj-c++.clean: obj-c++.mostlyclean + obj-c++.distclean: -rm -f objcp/config.status objcp/Makefile + obj-c++.maintainer-clean: -# # Stage hooks: obj-c++.stage1: stage1-start @@ -152,3 +171,5 @@ obj-c++.stageprofile: stageprofile-start -mv objcp/*$(objext) stageprofile/objcp obj-c++.stagefeedback: stagefeedback-start -mv objcp/*$(objext) stagefeedback/objcp + +config.status: objcp/config-lang.in diff --git a/gcc/objcp/objcp-spec.c b/gcc/objcp/objcp-spec.c new file mode 100644 index 0000000..8a44180 --- /dev/null +++ b/gcc/objcp/objcp-spec.c @@ -0,0 +1,38 @@ +/* This file is part of GCC. + +GNU CC is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GNU CC is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GCC; see the file COPYING3. If not see +<http://www.gnu.org/licenses/>. */ + +#include "config.h" +#include "system.h" +#include "gcc.h" + +#include "coretypes.h" +#include "tm.h" + +void lang_specific_driver( int *in_argc ATTRIBUTE_UNUSED, + const char *const **in_argv ATTRIBUTE_UNUSED, + int *in_added_libraries ATTRIBUTE_UNUSED ) +{ + return; +} + +/* Called before linking. Returns 0 on success and -1 on failure. */ +int lang_specific_pre_link( void ) +{ + return 0; +} + +/* Number of extra output files that lang_specific_pre_link may generate. */ +int lang_specific_extra_outfiles = 0; -- 1.7.2.1 From f7f2e04d83902f8f41f9917cfde54b4918ec3cbc Mon Sep 17 00:00:00 2001 From: redbrain <redbrain@gcc.gnu.org> Date: Wed, 18 Aug 2010 05:29:12 +0100 Subject: [PATCH 2/2] fix spelling error in the objcp-unisntall make rule --- gcc/objcp/Make-lang.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gcc/objcp/Make-lang.in b/gcc/objcp/Make-lang.in index 64ef647..993efad 100644 --- a/gcc/objcp/Make-lang.in +++ b/gcc/objcp/Make-lang.in @@ -141,7 +141,7 @@ obj-c++.install-common: installdirs obj-c++.install-plugin: obj-c++.uninstall: - -rm -rf $(DESTDIR)/$(bindir)/$(GCCOBJ-C++_INSTALL_NAME)$(exeext) + -rm -rf $(DESTDIR)/$(bindir)/$(GCCOBJCP_INSTALL_NAME)$(exeext) # Clean hooks: # A lot of the ancillary files are deleted by the main makefile.
Hey Following up this thread on gcc-help: http://gcc.gnu.org/ml/gcc-help/2010-08/msg00087.html I added a objc and objcp compiler drivers, the objc one works so far as much as i can tell i tested a hello world program with gccobjc hello.m and the resulting a.out worked. The compiler driver code i added for both is a vanilla driver, which could fail though, since i don't tell anything to explicitly link their respective runtime libraries though i would doubt the objc front-end i just tested would generate working code without doing that so i may be fine as is. I am having problems with the objcp one so far it doesn't seem to get installed so i need to look into this though i would like to get a review on the patch as it stands so as i know i am on the right track. --Phil From 8b24db0dc92ba9fb1b91955fd0e358d89a2c462e Mon Sep 17 00:00:00 2001 From: redbrain <redbrain@gcc.gnu.org> Date: Wed, 18 Aug 2010 04:35:41 +0100 Subject: [PATCH 1/2] add obj-c front-ends with compiler drivers --- gcc/objc/Make-lang.in | 39 ++++++++++++++++++++++++++++----------- gcc/objc/objc-spec.c | 38 ++++++++++++++++++++++++++++++++++++++ gcc/objcp/Make-lang.in | 45 +++++++++++++++++++++++++++++++++------------ gcc/objcp/objcp-spec.c | 38 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 137 insertions(+), 23 deletions(-) create mode 100644 gcc/objc/objc-spec.c create mode 100644 gcc/objcp/objcp-spec.c