how about a 'snowleopardfixes' library port?

Ken Cunningham ken.cunningham.webuse at
Tue Aug 23 10:26:28 PDT 2016


I thought of that, but 

sudo install_name_tool -add_rpath /opt/local/lib /opt/local/lib/libsnowleopardfixes.a.dylib

didn't solve the issue. Sorry I left that step out.

then I went big-gun and set the DYLIB_FALLBACK_LIBRARY_PATH

but that didn't work either.

I'll keep plugging.

As Ryan says, if the upstream would just improve their use of glib a bit and test for getline, then we wouldn't need to go through all this nonsense. But it is very very common that they don't check for getline.


On 2016-08-23, at 10:16 AM, Clemens Lang wrote:

> Hi,
> On Tue, Aug 23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote:
>> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib
> You need -install_name ${prefix}/lib/libsnowleopardfixes.a.dylib here.
>> configure:3663: ./conftest
>> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>>  Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>>  Reason: image not found
>> ./configure: line 3665: 50401 Trace/BPT trap          ./conftest$ac_cv_exeext
>> configure:3667: $? = 133
>> configure:3674: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
>> configure:3676: error: cannot run C++ compiled programs.
>> If you meant to cross compile, use `--host'.
> This check just tests whether you can run compiled programs. Because
> your library does not have a correct install name it is not found by the
> loader, which causes the test program to fail.
> The configure script just happens to assume that you might be
> cross-compiling if you cannot run the generated binaries.
> -- 
> Clemens

More information about the macports-dev mailing list