gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]