Since .dylib is the standard extension for libraries on OSX, it's probably a better idea to have an #ifdef that checks for the operating system and chooses the correct extension based on it.
If you ever wish to support Windows in the future, they use .DLL. On 2 July 2018 at 22:15, Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: > Hi Xiao-Yong, > > true, but *lib_file_i**o* has been replaced by *⎕FIO* and will be removed > in the near future. > > I would also suppose that *lib_file_io.dylib* can be renamed to > *lib_file_io.**so* after building it. > > /// Jürgen > > > On 07/02/2018 03:44 PM, Xiao-Yong Jin wrote: > > I haven't checked. > But having lib_file_io.dylib instead of lib_file_io.so might create problems > with ⎕FX which uses dlopen. > > Can you check > > 'lib_file_io.so' ⎕FX 'FILE_IO' > > and subsequent FILE_IO functionalities still work or not? > > > On Jun 30, 2018, at 5:33 PM, Peter Teeson <peter.tee...@icloud.com> > <peter.tee...@icloud.com> wrote: > > Hi Jürgen: > > Good news…. That seems to have worked. > I deleted the /usr/local/lib/apl dir as well as the /usr/local/include/apl dir > > In my case I had to install the following auto tools: > autoconf-2.69 libtool-2.4.6 automake-1.15 > > Then Gandalf:~ pteeson$ svn co http://svn.savannah.gnu.org/svn/apl/trunk > gnuapl > > Then followed items 1-5 per your instructions. > > Then Gandalf:~ pteeson$ ls /usr/local/lib/apl > lib_file_io.0.dylib lib_template_F12.0.dylib libapl.0.dylib > lib_file_io.a lib_template_F12.a libapl.a > lib_file_io.dylib lib_template_F12.dylib > libapl.dyliblib_file_io.la lib_template_F12.la > libapl.la > lib_sql.0.dylib lib_template_OP1.0.dylib libemacs.0.dylib > lib_sql.a lib_template_OP1.a libemacs.a > lib_sql.dylib lib_template_OP1.dylib libemacs.dyliblib_sql.la > lib_template_OP1.la libemacs.la > lib_template_F0.0.dylib lib_template_OP2.0.dylib workspaces > lib_template_F0.a lib_template_OP2.a wslib3 > lib_template_F0.dylib lib_template_OP2.dylib wslib4 > lib_template_F0.la lib_template_OP2.la wslib5 > > Note that some of the .dylibs have version numbers as part of the lib name. > This conforms to Apple’s Dynamic Libraries Programming Topics documentation > > So far so good… I will now proceed with the original experiment…. > > Thanks for the help and support….. > > respect…. > > Peter > > > On Jun 30, 2018, at 6:00 AM, Juergen Sauermann > <juergen.sauerm...@t-online.de> <juergen.sauerm...@t-online.de> wrote: > > Hi Peter, > > if I compare the rules in Makefile.am for the libraries mentioned below, then > it seems > like there is one line which sets the xxx_la_LDFLAGS for those libraries xxx > that then fail > to properly build the dylibs. Removing that line may fix your problem (it may > create > others but we willl see), > > Please try the following: > > 1. remove the line that reads: > > lib_file_io_la_LDFLAGS = -avoid-version -module -shared -export-dynamic > > from file src/native/Makefile.am > > > 2. remove the line that reads: > > libapl_la_LDFLAGS += -avoid-version -module -shared -export-dynamic > > from file src/Makefile.am > > > 3. run command autoreconf in the top-level directory (the one that has the > subdir named src). That > creates a fresh Makefile.in file for every Makefile.am, > > > 4. run ./configure --with-libapl > > > 5. run make and sudo make install > > > It may or may not be necessary to run make clean before step 5 in the src and > src/native.directories if > there should be stale .la files. > > /// Jürgen > > > On 06/29/2018 07:52 PM, Peter Teeson wrote: > > Hi Jürgen: > Sorry for delayed reply I was AFK. > I just now did the following: > (0) Made a new partition (logical volume) and > installed macOS Yosemite 10.10.5 > installed Command LineTools (Apple's package of ld, libel, make, gcc, > etc, etc) > (1) Checked out svn1053 in new dir gnuapl in my home dir > Gandalf:~ pteeson$ pwd /Users/pteeson > Gandalf:~ pteeson$ svn co http://svn.savannah.gnu.org/svn/apl/trunk > gnuapl > (2) Gandalf:~ pteeson$ cd gnuapl > (3) Gandalf:gnuapl pteeson$ ./configure --with-libapl > checking for gcc... gcc > …... > (4) make > Gandalf:gnuapl pteeson$ make > /Library/Developer/CommandLineTools/usr/bin/make all-recursive > Making all in build > ….. > > > libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/libapl.so > -bundle ,,,,, > (5) sudo make install > libtool: install: /usr/bin/install -c .libs/libapl.so > /usr/local/lib/apl/libapl.so > > So completely vanilla, out of the box, build. > > Gandalf:gnuapl pteeson$ ls /usr/local/lib/apllib_file_io.la > lib_template_OP1.dylib > lib_file_io.so lib_template_OP1.la > lib_sql.0.dylib lib_template_OP2.0.dylib > lib_sql.a lib_template_OP2.a > lib_sql.dylib lib_template_OP2.dyliblib_sql.la > lib_template_OP2.la > lib_template_F0.0.dylib libapl.la > lib_template_F0.a libapl.so > lib_template_F0.dylib libemacs.0.dylib > lib_template_F0.la libemacs.a > lib_template_F12.0.dylib libemacs.dylib > lib_template_F12.a libemacs.la > lib_template_F12.dylib workspaces > lib_template_F12.la wslib3 > lib_template_OP1.0.dylib wslib4 > lib_template_OP1.a wslib5 > > What I find interesting is that most of the libraries are either .a, .la, or > .dylib. > But the exceptions are lib_file_io.so and libapl.so > > So the gnuapl package, as a checked out, knows how to make .dylibs. > It’s just those two that seem to have a problem. > > How do we figure out what we need to do to fix them? > > BTW I have the complete Terminal output saved if we need to dig into it. > > respect…. > > Peter > > > > > > >
