* gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
@ 2019-02-21 6:07 J T Nelson
2019-02-21 12:33 ` Janne Blomqvist
2019-02-21 17:43 ` Iain Sandoe
0 siblings, 2 replies; 9+ messages in thread
From: J T Nelson @ 2019-02-21 6:07 UTC (permalink / raw)
To: fortran
All:
I have been using versions of gfortran 4 to produce relatively simple vba-callable libs for EXCEL 2011.
I employed the -march=i386 and -m32 switches during compilation and linking.
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.
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.
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.
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.
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
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-02-21 6:07 gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave J T Nelson
@ 2019-02-21 12:33 ` Janne Blomqvist
2019-02-22 4:46 ` J T Nelson
2019-02-21 17:43 ` Iain Sandoe
1 sibling, 1 reply; 9+ messages in thread
From: Janne Blomqvist @ 2019-02-21 12:33 UTC (permalink / raw)
To: J T Nelson; +Cc: Fortran List
On Thu, Feb 21, 2019 at 8:07 AM J T Nelson <nelsonjt@earthlink.net> wrote:
> i attempted compiling and linking with or without the -mx32 switch during linking and/or compiling, and the linker produces a library.
I don't know what the solution to your problem is, except to note that
-mx32 is extremely unlikely to be the solution. X32 is a
Linux-specific ABI for using 32-bit pointers in x86-64 long mode. See
https://en.wikipedia.org/wiki/X32_ABI .
--
Janne Blomqvist
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-02-21 6:07 gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave J T Nelson
2019-02-21 12:33 ` Janne Blomqvist
@ 2019-02-21 17:43 ` Iain Sandoe
[not found] ` <69EE3C5C-81EF-4E81-B7E7-D4C599C3F3EE@googlemail.com>
1 sibling, 1 reply; 9+ messages in thread
From: Iain Sandoe @ 2019-02-21 17:43 UTC (permalink / raw)
To: J T Nelson; +Cc: Fortran List
Hi,
> On 20 Feb 2019, at 20:07, J T Nelson <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 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
>
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-02-21 12:33 ` Janne Blomqvist
@ 2019-02-22 4:46 ` J T Nelson
0 siblings, 0 replies; 9+ messages in thread
From: J T Nelson @ 2019-02-22 4:46 UTC (permalink / raw)
To: Janne Blomqvist; +Cc: Fortran List
> On Feb 21, 2019, at 4:33 AM, Janne Blomqvist <blomqvist.janne@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 8:07 AM J T Nelson <nelsonjt@earthlink.net> wrote:
>> i attempted compiling and linking with or without the -mx32 switch during linking and/or compiling, and the linker produces a library.
>
> I don't know what the solution to your problem is, except to note that
> -mx32 is extremely unlikely to be the solution. X32 is a
> Linux-specific ABI for using 32-bit pointers in x86-64 long mode. See
> https://en.wikipedia.org/wiki/X32_ABI .
>
> --
> Janne Blomqvist
-mx32 seems to do something similar to -m32, as indicated in the manuals.
-mx32 is an option in GCC, not in gfortran, judging from the manual.
Interestingly, compiling with -m32 produces an error when linking the objects with gfortran 8.2, which identifies the object as compiled for i386.
Evidently, i386 code is compiled with gfortran 8.2. I just can’t link it with apple’s linker.
Evidently, -mx32 has no significance during compilation with gfortran 8.2
I had no luck using the -mx32 switch during linking, regardless.
The link to wikipedia is very interesting.
Thanks.
Jim
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
[not found] ` <69EE3C5C-81EF-4E81-B7E7-D4C599C3F3EE@googlemail.com>
@ 2019-03-06 16:03 ` J T Nelson
2019-03-09 13:02 ` Iain Sandoe
0 siblings, 1 reply; 9+ messages in thread
From: J T Nelson @ 2019-03-06 16:03 UTC (permalink / raw)
To: Iain Sandoe; +Cc: Fortran List
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
>>>
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-03-06 16:03 ` J T Nelson
@ 2019-03-09 13:02 ` Iain Sandoe
2019-03-09 16:46 ` J T Nelson
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Iain Sandoe @ 2019-03-09 13:02 UTC (permalink / raw)
To: J T Nelson; +Cc: Fortran List
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
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-03-09 13:02 ` Iain Sandoe
@ 2019-03-09 16:46 ` J T Nelson
2019-03-10 6:12 ` J T Nelson
2019-03-11 3:19 ` J T Nelson
2 siblings, 0 replies; 9+ messages in thread
From: J T Nelson @ 2019-03-09 16:46 UTC (permalink / raw)
To: Iain Sandoe; +Cc: Fortran List
With EXCEL 2011, High Sierra, and earlier gfortran, I installed the dylib in ~/lib.
I simply copied the dylib into ~/lib with the usual bash cp command.
I have also installed the dylib in the /Applications folder for EXCEL 2019, including sub folders!
I had to use the sudo command to do it, as a root user.
I will be trying a few other things in the next few days to make this work with EXCEL 2019 under Mojave.
Somebody else out there must have succeeded at this.
We might want to change the thread on this a bit to refer to EXCEL 2019 VBA.
Jim
> 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
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-03-09 13:02 ` Iain Sandoe
2019-03-09 16:46 ` J T Nelson
@ 2019-03-10 6:12 ` J T Nelson
2019-03-11 3:19 ` J T Nelson
2 siblings, 0 replies; 9+ messages in thread
From: J T Nelson @ 2019-03-10 6:12 UTC (permalink / raw)
To: Iain Sandoe; +Cc: Fortran List
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
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave
2019-03-09 13:02 ` Iain Sandoe
2019-03-09 16:46 ` J T Nelson
2019-03-10 6:12 ` J T Nelson
@ 2019-03-11 3:19 ` J T Nelson
2 siblings, 0 replies; 9+ messages in thread
From: J T Nelson @ 2019-03-11 3:19 UTC (permalink / raw)
To: Iain Sandoe; +Cc: Fortran List
Well, installing as indicated by Microsoft for EXCEL 2016 did not work.
Interestingly, EXCEL 2019 looks for and finds add-ins in ECEL 2011’s /Applications folder!!!! After all that!
Time to call Microsoft!
Jim
> 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
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-03-11 3:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-21 6:07 gfortran 8.2: compiling and linking dylib for excel 2011 VBA under OSX Mojave J T Nelson
2019-02-21 12:33 ` Janne Blomqvist
2019-02-22 4:46 ` J T Nelson
2019-02-21 17:43 ` Iain Sandoe
[not found] ` <69EE3C5C-81EF-4E81-B7E7-D4C599C3F3EE@googlemail.com>
2019-03-06 16:03 ` J T Nelson
2019-03-09 13:02 ` Iain Sandoe
2019-03-09 16:46 ` J T Nelson
2019-03-10 6:12 ` J T Nelson
2019-03-11 3:19 ` J T Nelson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).