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

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

I inserted error coding into the VBA stub routine and added GrantAccessToMultipleFiles to request access.
The indicated error on the call is 53 - File not found.
I tried stripping “.dylib" and “lib" from the dynamic library name. No luck.
This is starting to look like a bug in EXCEL 2019 VBA rather than an API problem.
 

> On Mar 9, 2019, at 5:02 AM, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> Hi Jim,
> 
>> On 6 Mar 2019, at 16:03, J T Nelson <nelsonjt@earthlink.net> wrote:
> 
>> I upgraded to EXCEL 2019 and I am not able to call 64-bit dylibs created with fortran 8.2.
> 
> Is there any guidance from Microsoft on how to make such a plugin? (even if it assumes use of C, that would help isolate issues).
> 
> (I take it this is an officially supported action? ..)
> 
>> Evidently, EXCEL is “sandboxed”, but I am not sure if that is the problem.
> 
> If you’re trying to use DYLD_LIBRARY_PATH or its friends to insert the library before some MS-provided one, then SIP will defeat you - but probably some rpath solution can be found.
> 
> When, in past editions, you had a working solution, where did you place the plugin library?
> 
> Have you tried placing the new one in ~/lib ?
> 
> What’s the install path you use for the plugin lib?
> 
> It is possible to self-codesign exes/dylibs *but* there are some paths on the system for which the signing must use an apple certificate.  However, I don’t see why codesigning would be needed for a maths-style library - which doesn’t need any special ports or elevated privs. to operate.
> 
> Is the excel install drag & drop?
> 
> (if so, placing it somewhere other than /Applications could give you a different set of sandboxing [e.g. I usually have a /DnDApps folder for drag and drop installs, that are not part of the base system])
> 
> —
> 
> general macOS security issues are not really a GCC/gfortran problem - however, in case we have a build problem - let’s pursue it a little further.
> 
> Iain
> 
> 
>> 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
>>>>> 
>>>> 
>>> 
>> 
>