Frank Heckenbach wrote:
Adriaan van Os wrote:
The most recent Apple version of GCC that I can find on the web (http://www.opendarwin.org/en/news.php#20) is "gcc3-1205 Darwin". Installing and using it doesn't change reported problems. Yet, I can use it to build a new GCC from the standard GCC-3.2.1 sources. This gives me a GCC-3.2.1 that installs and runs on Darwin. If I use this new GCC (3.2.1) to build GPC 20021128, there are no building problems: reported problems 1 to 4 have disappeared !
I don't quite understand. With the downloaded GCC, you are able to build gcc-3.2.1, but building GPC with gcc-3.2.1 sources fails. But the problems (#1, 2 and 3) are related to parts of the GCC sources that are unchanged by GPC. So compiling the same sources once works and once fails!? I must be missing something ...
Problems #1, 2 and 3 are related to GCC (not GPC), so to build "GCC 3.2.1" I had to ignore problem #1 (which doesn't seem to influence the build process). Also, I had to apply the hacks for problems #2 and #3. However, this new (hacked) GCC 3.2.1 compiler now causes problems when I try to repeat what (I think) I did. Probably, I have mixed up versions and my statement above is wrong. Well, I have done quite a lot of experimenting with different versions -- on the fly trying to learn UNIX.
I will do my best to find more information on the web on building GCC 3.2.1 on Darwin.
Unfortunately, the linking problem is still the same:
[G4:doc/gpc/demos] adriaan% gpc hello.pas /usr/bin/ld: /usr/lib/gcc-lib/powerpc-apple-darwin6.0/3.2.1/libgpc.a(init.o) malformed object (bad indirect symbol table entry (76) (symbol at index 241 is not external)
[...]
When I look in gpclib.a (with otool), I find the following entries for these indices. They all read:
"Indirect symbols for (__DATA,__nl_symbol_ptr) ... entries" address index name 0x00001b88 241 _fini_GPC_Init 0x00006624 972 _fini_GPC_Error 0x00001fa0 435 _fini_GPC_Getopt 0x00002424 1251 _fini_GPC_String 0x000018e0 570 _fini_GPC_String2 0x0000095c 235 _fini_GPC_Heap 0x00001520 431 _fini_GPC_Files 0x000005c8 178 _fini_GPC_Endian 0x000081c8 2390 _fini_GPC_Filename 0x00001078 385 _fini_GPC_Math 0x00000260 96 _fini_GPC_Move 0x000008e8 281 _fini_GPC_Numtodec 0x00000ce0 251 _fini_GPC_Random 0x000001b4 77 _fini_GPC_Rtsc 0x0000115c 774 _fini_GPC_Sets 0x00004828 933 _fini_GPC_Time
I hope this additional information is useful in finding the cause of the linking problem.
Try this (patch may need manual applying, since I've changed some other things in my copy meanwhile).
*** p/parse.y.orig Fri Jan 3 09:44:04 2003 --- p/parse.y Fri Jan 3 09:49:25 2003
*** 792,799 **** tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (chainon (build_tree_list (NULL_TREE, static_id), ! build_tree_list (NULL_TREE, void_type_node)), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); --- 792,798 ---- tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (build_tree_list (NULL_TREE, void_type_node), context, NULL_TREE, 0)) YYERROR1; store_parm_decls ();
Thanks a lot !!
Superb news ----- GPC builds on Mac OS X !!! Hello.pas compiles and runs !!!
Next step is to run a lot of tests. More news to follow.
Regards,
Adriaan van Os