[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Fwd: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxi
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Fwd: Patch for gcl-2.6.7 on MacOSX(10.4.2) to build maxima-5.9.[12] and so on. |
Date: |
01 Dec 2005 18:26:46 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Aurelien! U da man!
I've committed your stuff with minor mods to Version_2_6_8pre and cvs
head. I've built the former in ansi mode on our mutual machine at
utexas and used this to successfully build maxima 5.9.2 and pass all
tests.
I had to
1) revert void *my_sbrk to char *my_sbrk. Can we use a name which
does not conflict with any system routine?
2) Add _setjmp(env) to plttest.c to get both _setjmp and __setjmp
symbols. I suspect there is a macosx version dependency to the
name mangling issue we need to work out.(not committed)
3) No root nor tcl/tk on the machine in question, so I cannot
reproduce this issue, but I don't see where my_free and my_malloc
appear in o/alloc.c???? Am I missing something dumb?
Will look at axiom, acl2, and cvs head next. May I request:
1) That we elide the diagnostic material output on save system? This
might alarm the typical user. BTW, have confirmed that the old
save-system bug we were chasing in 2.6.6 is gone, or at least
intermittent :-).
2) That we see about scaling the heap size from configure like on
other platforms?
Take care, and thanks again to you both!
Aurelien Chanudet <address@hidden> writes:
> Hi all,
>
> I've fixed most compilation issues (see attached patches ; I may have
> forgotten some).
>
> Just some issue concerning symbol mangling : although C symbols on
> Darwin are prepended by leading underscore, it does not appear to be
> possible to refer directly to _getc (in plt.h). getc (without the
> leading underscore) should be used instead.
>
> Can someone contribute back to the binutils maintainers the code in
> mach-o.h, mach-o.c and mach-o-reloc.c ?
>
> I get the following error :
>
> gcc -no-cpp-precomp guis.o tkAppInit.o tkMain.o -o gcltkaux -L/sw/lib
> -ltk8.4 -L/sw/src/tcltk-8.4.6-2/tk8.4.6/unix -ltk8.4 -L/usr/X11R6/lib
> -lX11 -I/usr/X11R6/include -L/sw/lib -ltcl8.4 `echo -framework
> CoreFoundation | sed -e s:-lieee::g` `echo -lintl -lm -lgmp
> -lreadline -lncurses | sed -e 's/-lncurses/ /'` /sw/lib/libintl.dylib
> ../o/gcllib.a
> /usr/bin/ld: warning -L: directory name
> (/sw/src/tcltk-8.4.6-2/tk8.4.6/unix) does not exist
> /usr/bin/ld: warning multiple definitions of symbol _tclPlatStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> /usr/bin/ld: warning multiple definitions of symbol _tclIntStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
> /usr/bin/ld: warning multiple definitions of symbol _Tcl_InitStubs
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
> /usr/bin/ld: warning multiple definitions of symbol _tclStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
> /usr/bin/ld: warning multiple definitions of symbol _tclIntPlatStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
> /usr/bin/ld: Undefined symbols:
> _my_free
> _my_malloc
> collect2: ld returned 1 exit status
>
> my_free and my_malloc are defined in o/alloc.o, which apparently isn't
> supplied to the linker. What's the best way to fix this ?
>
> Thanks & regards,
> Aurelien
>
> On 01 Dec 2005 11:46:41 -0500, Camm Maguire <address@hidden> wrote:
> > Greetings!
> >
> > Would either of you two wonderful souls have any time in the next few
> > days to update the bfd macosx support in GCL to the latest binutils
> > version? I've incorporated the patches of Satoshi Adachi into cvs
> > Version_2_6_8pre and added the #include "mach-o-reloc.c" to mach-o.c.
> > Unfortunately this does not compile -- at the minimum these lines need
> > commenting out of the new upstream mach-o.c:
> >
> > /*#define bfd_mach_o_get_reloc_upper_bound
> > _bfd_norelocs_get_reloc_upper_bound*/
> > /*#define bfd_mach_o_canonicalize_reloc _bfd_norelocs_canonicalize_reloc*/
> > /*#define bfd_mach_o_bfd_reloc_type_lookup
> > _bfd_norelocs_bfd_reloc_type_lookup*/
> > /*#define bfd_mach_o_bfd_get_relocated_section_contents
> > bfd_generic_get_relocated_section_contents*/
> >
> >
> > Also, one needs to add back the _ist stuff on which Aurelien's code
> > depends, or find a way to make the
> > bfd_mach_o_get_indirect_section_contents routine use the new upstream
> > mach_o_data_struct:
> >
> >
> > typedef struct mach_o_data_struct
> > {
> > bfd_mach_o_header header;
> > bfd_mach_o_load_command *commands;
> > - bfd_mach_o_ist *ist;
> > - bfd_mach_o_symtab_command *st;
> > - bfd_mach_o_dysymtab_command *dyst;
> > unsigned long nsymbols;
> > asymbol *symbols;
> > unsigned long nsects;
> > @@ -596,24 +509,22 @@
> >
> > I've achieved a local compile which does not work, but you two could
> > obviously do this much more efficiently than I if you have the time.
> >
> > (BTW
> >
> > export CVS_RSH=ssh
> > export CVSROOT=:ext:address@hidden:/cvsroot/gcl
> > cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
> >
> > )
> >
> >
> > 足立 聡 <address@hidden> writes:
> >
> > > Hello,
> > >
> > > On 2005/11/05, at 9:33, Camm Maguire wrote:
> > >
> > > > Greetings!
> > > >
> > > > Well, this is about one of the most magnificent GCL messages I've read
> > > > in recent memory! Thank you so much! This is exactly the kind of
> > > > thoroughness and diligence these sort of problems demand, IMHO, and
> > > > the patience and time to follow through adequately, as you have done,
> > > > can be quite rare at times.
> > >
> > > Thank you very much. I am happy to hear that.
> > >
> > > > I will work on getting your material into 2.6.8pre (cvs tag
> > > > Version_2_6_8pre) asap. There is likely some additional work here to
> > > > do in this regard, as I've upgraded the binutils version, but not yet
> > > > tested our custom Macosx stuff. And thank you for indicating that GCL
> > > > has users on the Mac -- this helps us focus our priorities.
> > >
> > > And thank you very much for your effort as the maintainer of GCL.
> > > Within a week, I try to find some amount of time to download
> > > the most new version of the source code for GCL
> > > from the CVS tree and to compile it on my Mac.
> > > I will inform the result to you. If there is any problem in the
> > > compilation, I will try to fix it by myself at first.
> > >
> > > > Would you consider volunteering to be a GCL developer?
> > >
> > > Yes with pleasure.
> > > Though I can find only not a large amount of time to contribute
> > > the development of GCL, I will try the source code of GCL to work
> > > on MacOSX. If it does not work, I cannot use GCL and Maxima on
> > > my Mac. (I want to continue using GCL for Maxima, because I have
> > > been using GCL until now.)
> > >
> >
> > Great!
> >
> > OK, the first step to grant you cvs write access is for you to
> > register as a user on the savannah.gnu.org website, and send me your
> > username.
> >
> > Take care,
> >
> >
> > > Yours,
> > >
> > > Satoshi Adachi
> > >
> > >
> > >
> > >
> >
> > --
> > Camm Maguire address@hidden
> > ==========================================================================
> > "The earth is but one country, and mankind its citizens." -- Baha'u'llah
> >
>
>
>
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah