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.dylib lib_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.dylib lib_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 > <[email protected]> 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 >> <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/apl >> lib_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.dylib >> lib_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 >> >> >> >
