Latest Erlang on Mac OS X Panther

[Eric Baur]

Doh!  I screwed up a one line patch. Impressive. Let's try again.
------------------------------------------------------------------

*** Makefile.in.orig	Sat Nov  1 09:59:57 2003
--- Makefile.in	Sat Nov  1 10:01:08 2003
***************
*** 138,144 ****
   ifeq ($(TARGET),win32)
   LIBS    = @LIBS@ @THR_LIBS@ 
-L$(ERL_TOP)/erts/obj$(TYPEMARKER)/$(TARGET) -lz
   else
! LIBS    = @LIBS@ @THR_LIBS@ -L$(ERL_TOP)/erts/obj/$(TARGET) -lz
   endif
   ELIB_FLAGS = -DENABLE_ELIB_MALLOC -DELIB_ALLOC_IS_CLIB 
-DELIB_HEAP_SBRK

--- 138,144 ----
   ifeq ($(TARGET),win32)
   LIBS    = @LIBS@ @THR_LIBS@ 
-L$(ERL_TOP)/erts/obj$(TYPEMARKER)/$(TARGET) -lz
   else
! LIBS    = @LIBS@ @THR_LIBS@ $(ERL_TOP)/erts/obj/$(TARGET)/libz.a
   endif
   ELIB_FLAGS = -DENABLE_ELIB_MALLOC -DELIB_ALLOC_IS_CLIB 
-DELIB_HEAP_SBRK



On Oct 31, 2003, at 10:23 AM, Sean Hinde wrote:

> It appears to be failing to find the already compiled zlib included in 
> the erts directory structure. This seems to suggest some weird error 
> which causes zlib to be compiled in a way which the linker can't use, 
> or some weird new compiler stufff in the final linking stage.
>
> Very odd.
>
> Sean
>
>
> On Friday, October 31, 2003, at 02:33  pm, Micael Karlberg wrote:
>
>> A google indicate that it's defined in zlib (zlib/zutil.h).
>>
>> /BMK
>>
>> Eric Newhuis writes:
>>> Just to keep this thread alive I will say that no, this doesn't seem 
>>> to
>>> be the only problem.  I've not had time to investigate further mostly
>>> due to my indulgence in attempting to get distel working on my 
>>> Panther
>>> Mac on R9B-0.
>>>
>>> I do remember that there were some problems copying files during the
>>> make.  And I do remember seeing another target complain about 
>>> undefined
>>> z_errmsg.  Perhaps if I knew what z_errmsg is I could take the next
>>> step.  I suppose I shall have to look at the erts source.
>>>
>>> I have no problem using the pre-built R9B-0 Mac OS/X release on
>>> Panther.   I've been using it for a week now without any problems.
>>> However I have not tried anything that invokes the GUI.
>>>
>>>
>>>> Is that linking problem only for the Shared Heap emulator?
>>>>
>>>> In that case, a simply workaround would be to comment out
>>>> the building of the Shared Heap emulator from the Makefile,
>>>> as it is not critical for building the rest of OTP.
>>
>> -- 
>> Micael Karlberg          Ericsson AB, Älvsjö Sweden
>> Tel:  +46 8 727 5668     EAB/UHK/KD - OTP Product Development
>> ECN:  851 5668           Mail: micael.karlberg@REDACTED
>> Fax:  +46 8 727 5775
>