Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave

[J T Nelson <nelsonjt at earthlink dot net>]

Update:
I upgraded to EXCEL 2019 and I am not able to call 64-bit dylibs created with fortran 8.2.  
Evidently, EXCEL is “sandboxed”, but I am not sure if that is the problem.
Jim


> On Feb 21, 2019, at 9:44 AM, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> … for some reason your ISP is blocking mine :-(
> 
> … hopefully they accept google!
> 
>> Begin forwarded message:
>> 
>> From: Iain Sandoe <iain@sandoe.co.uk <mailto:iain@sandoe.co.uk>>
>> Subject: Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
>> Date: 21 February 2019 at 07:42:48 GMT-10
>> To: J T Nelson <nelsonjt@earthlink.net <mailto:nelsonjt@earthlink.net>>
>> Cc: Fortran List <fortran@gcc.gnu.org <mailto:fortran@gcc.gnu.org>>
>> 
>> Hi,
>> 
>>> On 20 Feb 2019, at 20:07, J T Nelson <nelsonjt@earthlink.net <mailto:nelsonjt@earthlink.net>> wrote:
>>> \I have been using versions of gfortran 4 to produce relatively simple vba-callable libs for EXCEL 2011.
>> 
>> neat.
>> 
>>> I employed the -march=i386 and -m32 switches during compilation and linking.
>> 
>> Will the VBA module work without these switches?
>> (i.e. does it support 64bit callable libs?)
>> 
>> - that would be your simplest solution since...
>> 
>>> All was well until upgrading to Apple OSX Mohave and downloading Xcode with the latest command line tools.
>>> Then, I received warnings that the i386 switch was deprecated.
>>> Still the libraries worked without a problem.
>> 
>> 
>> … From Mojave (10.14) onwards the use of 32b is not certain to work (that’s a somewhat imprecise statement, I realise) … 
>> .. imprecise because, some (maybe most) 32bit APIs still exist in 10.14 - and thus older 32b stuff will “work” (with a system pop-up warning that they are not optimised .. or similar)
>> 
>> However, fudging 32bit is not a long-term solution, and it could be that one day (even the next release for all I know) it will be removed completely.
>>> 
>>> However, I subsequently installed gfortran 8.2.
>>> The -march=386 and -m32 switches produced errors during linking, though the compiler produced objects.
>>> The error messages indicate that the objects were compiled for i386 architecture and are ignored.
>>> 
>>> i attempted compiling and linking with or without the -mx32 switch during linking and/or compiling, and the linker produces a library.
>> 
>> As commented by Janne mx32 has no meaning on macOS / Darwin / OSX.
>> 
>>> I have tried -march=native as well as -march=haswell.
>>> However, the library returns bad data.
>>> I use the same calling conventions in the VBA code for EXCEL 2011, and I believe the VBA finds the library.
>> 
>> The latest Xcode imposes the deprecation of 32bit stuff, the errors you mention are intentional from XCode .. 
>> 
>> I would say your only reasonable solution if you have to do 32b is to go to developer.apple.com <http://developer.apple.com/> and login and download an earlier (working) xcode command line tool set.  Xcode usually lets you select which command line tools you use from a pop up menu in the prefs.
>> 
>> If that fails, then you are going to need to be a bit more creative, and install the command line tools by hand (somewhere) - plus use xcode-select to activate them.
>> 
>> (there are man pages and online resources for xcode-select).
>> 
>>> 
>>> Running "nm libFILTER.dylib” indicates that the subroutines in the dylib are labeled as before with gfortran 4, specifically with underscores before and after the subroutine name. 
>>> 
>>> I can substitute an older version of the dylib, compiled with gfortran 4.2, and VBA calls work.
>>> 
>>> I regard this behavior as a bug, either in gfortran 8.2, or in the Darwin linker.
>>> They obviously don’t work together.
>>> This is obviously an X86-64 problem.
>> 
>> It’s neither a bug nor an x86-64 problem - it’s a conscious decision on the part of the system vendor to deprecate and remove 32b support from macOS - you could file a radar, but I don’t hold out a lot of hope for policy change.
>> 
>> I’m out of the office right now so probably only see email sporadically, Dominique might be able to help you in the meantime,
>> 
>> Iain
>> 
>>> 
>>> Any help would be appreciated.
>>> I have searched various blogs, and will likely participate in a blog if you recommend one.
>>> 
>>> I am running OSX Mojave on a Mac Book Air, Model A1466 
>>> Below is the makefile used to produce the library libFILTER.dylib:
>>> 
>>> I am not a professional programmer, but have been programming seismic codes in F77 for 40 years, and lately F95.
>>> 
>>> Thanks in advance.
>>> 
>>> JTNelson    nelsonjt@earthlink.net <mailto:nelsonjt@earthlink.net>
>>> 
>>> Incidentally, except for this problem, I find gfortran to be particularly good and useful !!!
>>> I use the intel IFORT compiler at work on a HP workstation with XEON processors.
>>> The DLLs produced with IFORT work just fine.
>>> 
>>> #FILTER dynamic library for OSX EXCEL VBA
>>> #Makefile for gnumake
>>> #gnuform compiler
>>> #
>>> OBJS =  \
>>> 	dbnpass.o  \
>>> 	dhipass.o  \
>>> 	DEVLMEM.o  \
>>> 	MEMCOFD.o \
>>> 	dlopass.o
>>> 
>>> SRCS = $(OBJS:.o=.f) $(OBJS:.o=.F90) $(OBJS:.o=.FOR) $(OBJS:.o=.F) $(OBJS:.o.f90)
>>> 
>>> 
>>> DEBUG  = -c -Wall -mx32 -march=haswell -mtune=haswell -fd-lines-as-comments 
>>> 
>>> 
>>> DEBUGF90  = -c -Wall -mx32 -march=haswell -mtune=haswell
>>> 
>>> 
>>> .SUFFIXES: .lib .o .obj .f .for .f90 .FOR .F90 .c .prj 
>>> 
>>> libFILTER.dylib: $(OBJS) makefile
>>> 
>>> 	gfortran -mx32 -static  -static-libgfortran -dynamiclib -gfull -o $@  $(OBJS)
>>> 
>>> .f.o:
>>> 	gfortran $(DEBUG)   $(<)
>>> 
>>> .F.o:
>>> 	gfortran $(DEBUG)   $(<)
>>> 
>>> .FOR.o:
>>> 	gfortran $(DEBUG)   $(<)
>>> 
>>> .F90.o:
>>> 	gfortran $(DEBUGF90)   $(<)
>>> 
>>> .f90.o:
>>> 	gfortran $(DEBUGF90)   $(<)
>>> 
>>> print:
>>> 	print $(SRCS)
>>> 
>>> install:
>>> 	mv ./libFILTER.dylib /Users/JTN/lib/libFILTER.dylib
>>> 
>>> clean:
>>> 	rm ./*.o
>>> 
>> 
>