unorthodox build setup?

[Mark Brethen]

This is all I found in the Makefile:

libreduce.a: $(OBJ)
	rm -f libreduce.a
	ar rcs libreduce.a $(OBJ)

libreduce.so: $(OBJ)
	rm -f libreduce.so
	gcc $(FAT) -shared $(OBJ) -o libreduce.so

RedPy.so: $(OBJ) RedPy.o
	gcc $(FAT) -shared $(OBJ) RedPy.o $(shell python-config --ldflags) -o RedPy.so

and for the test binary:

lrtest: $(srcdir)/examples/lrtest.c libreduce.a $(srcdir)/reduce.h
	mkdir -p examples
	$(CC) $(FAT) -o examples/lrtest -I$(srcdir) -DREDUCE=$(REDUCE) $(srcdir)/examples/lrtest.c -L. -lreduce



Mark Brethen
mark.brethen at gmail.com



> On Oct 5, 2018, at 3:46 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> 
> On Oct 5, 2018, at 15:41, Mark Brethen wrote:
> 
>> running the lrtest binary fails:
>> 
>> brethen-air:examples marbre$ ./lrtest
>> dyld: Library not loaded: libreduce.so
>>  Referenced from: /opt/local/share/libreduce/x86_64-mac_10.12_sierra-darwin16.7.0/examples/./lrtest
>>  Reason: image not found
>> Abort trap: 6
>> 
>> I checked it using otool:
>> 
>> brethen-air:examples marbre$ otool -L lrtest
>> lrtest:
>> 	libreduce.so (compatibility version 0.0.0, current version 0.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
>> 
>> libreduce.so was copied to ${prefix}/lib. Should it be somewhere else?
>> 
>> 
> 
> 
> libreduce.so does not have the correct install_name set. The install_name needs to be set to the absolute path where the library will be installed.
> 
> Ideally it should be set passing the -install_name flag when the library is built.
> 
> If that's not easy to fix, you can run the install_name_tool program later to fix it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181005/9c468fa8/attachment.html>