I have a project which needs to use Libcrypto - and I have two versions of Libcrypto (libcrypto.a (from OpenSSL 1.1.1) built for ARM64) and (lcrypto.a (from OpenSSL 1.0.2) for Intel). Leaving aside the issues of whether it's good practice or not to have two different versions, I can say that if I include libcrypto.a then I can build and run on M1 and it works fine on M1. If I include lcrypto.a then I can build and run on Intel and it works fine on Intel. What I can't do is include them both (linker error - The linked library 'lcrypto.a' is missing one or more architectures required by this target: arm64.) - and if I can't include them both then I can't build a fat binary, and my app is less than entirely useful!
My question is How can I include both in my project - or where can I get (and how can I include) a fat version of Libcrypto? I've looked at this https://github.com/balthisar/openssl-xcframeworks/releases and this https://developer.apple.com/forums/thread/670631 but I'm none the wiser. I think I built a Fat Binary - but the Fat Binary I thought that I built doesn't work for either architecture!
Use command lipo to combine binaries
Compile Intel and ARM versions separately (arm version requires Xcode 12).
export MACOSX_DEPLOYMENT_TARGET=10.9
cp -r openssl-1.1.1t openssl-1.1.1t-arm64
cp -r openssl-1.1.1t openssl-1.1.1t-x86_x64
Build the Intel half
cd openssl-1.1.1t-x86_x64
./Configure darwin64-x86_64-cc shared
make
NOTE: For openssl-1.1.1q use -Wno-error=implicit-function-declaration as a configure parameter
Build the Arm half
export MACOSX_DEPLOYMENT_TARGET=10.15 /* arm64 only with Big Sur -> minimum might be 10.16 or 11.0 */)
cd ../openssl-1.1.1t-arm64
./Configure enable-rc5 zlib darwin64-arm64-cc no-asm
make
NOTE: For openssl-1.1.1q use -Wno-error=implicit-function-declaration as a configure parameter
To create universal binary use command lipo:
cd ..
mkdir openssl-mac
lipo -create openssl-1.1.1t-arm64/libcrypto.a openssl-1.1.1t-x86_x64/libcrypto.a -output openssl-mac/libcrypto.a
lipo -create openssl-1.1.1t-arm64/libssl.a openssl-1.1.1t-x86_x64/libssl.a -output openssl-mac/libssl.a
Verify that resulting binary contains both architectures:
file libcrypto.a libssl.a
libcrypto.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random library] [arm64]
libcrypto.a (for architecture x86_64): current ar archive random library
libcrypto.a (for architecture arm64): current ar archive random library
libssl.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random library] [arm64]
libssl.a (for architecture x86_64): current ar archive random library
libssl.a (for architecture arm64): current ar archive random library
PS: If you plan to use dynamic library combine dylib files using lipo and run instal_name_tool
cd openssl-mac
install_name_tool -id '#rpath/libcrypto.1.1.1.dylib' libcrypto.1.1.1.dylib
install_name_tool -id '#rpath/libssl.1.1.dylib' libssl.1.1.dylib
otool -D libssl.1.1.dylib /* to verify */
Result:
libssl.1.1.dylib:
#rpath/libssl.1.1.dylib
Even though this question already has an accepted answer, I'd like to mention that I found an easier way to do this that doesn't require using lipo, just in case it helps make someone else's life easier.
The trick is to force it to compile for both architectures simultaneously.
Before calling Configure in the openssl source directory, create a file somewhere convenient (for the purposes of explaining I'll just have it in the home folder) named cc, and have it contain the following text:
#!/bin/bash
if [[ $* == *-arch\ x86_64* ]] && ! [[ $* == *-arch\ arm64* ]]; then
echo Forcing compilation with arm64
cc -arch arm64 $#
else
cc $#
fi
That script will automatically add -arch arm64 to any compilation command that only includes -arch x86_64, and leave all other compilation commands unmodified.
Give it execute permissions:
chmod a+x ~/cc
Then execute the following in your shell to force compilation with this shell script:
export CC=/Users/yourname/cc
Then proceed with configuring and building as though for arm64, but tell it to compile as x86_64:
./Configure enable-rc5 zlib no-asm darwin64-x86_64-cc
make
make install
The resulting static libs and dylibs will already be x86_64 / arm64 universal!
I am trying to build MariaDB v10.3 with a musl tool chain on x86_64 Debian kernel v4.19. I have mainly been using the musl-gcc gcc wrapper to achieve this. The relevant packages I installed are as follows:
musl (1.1.21-2): standard C library
musl-dev (1.1.21-2): standard C library development files
musl-tools (1.1.21-2): standard C library tools
To build MariaDB, I first run:
CC=/usr/bin/musl-gcc cmake ../ -DWITHOUT_TOKUDB=1
which exits cleanly, and then I follow that up with:
make CC=/usr/bin/musl-gcc
which error with the following message:
Scanning dependencies of target strings-t
[ 12%] Building C object unittest/strings/CMakeFiles/strings-t.dir/strings-t.c.o
[ 12%] Linking CXX executable strings-t
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
make[2]: *** [unittest/strings/CMakeFiles/strings-t.dir/build.make:94: unittest/strings/strings-t] Error 1
make[1]: *** [CMakeFiles/Makefile2:731: unittest/strings/CMakeFiles/strings-t.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
Now I know the library that musl is looking for (libgcc_s.so) is located in /lib/gcc/x86_64-linux-gnu/8/ but my attempts to include the library using LDFLAGS or symlinking the library into /usr/lib/x86_64-linux-musl/ have failed.
Am I going about compiling MariaDB the right way? I imagine I am doing something wrong as Alpine Linux can run it.
Thus why don't looking how alpine is building it ?
https://git.alpinelinux.org/aports/tree/main/mariadb/APKBUILD?id=3ca8e70b047f37a01df42e3244014a6635893abc
seems they disable test
-DSKIP_TESTS=ON
ref: https://git.alpinelinux.org/aports/tree/main/mariadb/APKBUILD?id=3ca8e70b047f37a01df42e3244014a6635893abc#n186
And their ppc-glibc patch ?
https://git.alpinelinux.org/aports/tree/main/mariadb/ppc-remove-glibc-dep.patch?id=3ca8e70b047f37a01df42e3244014a6635893abc
I will update this answer when I become completely successful, but the solution thus far has been to use musl-cross-make to compile all libraries and such to specifically target musl. Since getting musl-cross-make I have been building all the dependencies from scratch (which is not fun :)). Thus far, I have gotten a more-or-less successful configuration and I am working on compilation (hammering out the last few dependencies).
I am using the following script to build things:
#!/bin/bash
set -euo pipefail
# musl paths
MUSL_PREFIX='/usr/local/x86_64-linux-musl'
MUSL_INC="$MUSL_PREFIX/include"
MUSL_LIB="$MUSL_PREFIX/lib"
CC='/usr/local/bin/x86_64-linux-musl-gcc'
CXX='/usr/local/bin/x86_64-linux-musl-g++'
#
# CMake couldn't locate lz4 when I installed it manually, so we bundle
# it in with the MariaDB build
#
wget https://github.com/lz4/lz4/archive/v1.7.5.tar.gz
tar -xzf v1.7.5.tar.gz
rm v1.7.5.tar.gz
mv lz4-1.7.5 /home/ajg/mariadb/storage/mroonga/vendor/groonga/vendor/
# Configure the build
CC="$CC" \
CXX="$CXX" \
LDFLAGS="-L$MUSL_LIB -Wl,-rpath,$MUSL_LIB" \
CFLAGS="-I$MUSL_INC" \
CXXFLAGS="-I$MUSL_INC" \
CPPFLAGS="-I$MUSL_INC" \
CMAKE_PREFIX_PATH="$MUSL_PREFIX" \
cmake . -DWITHOUT_TOKUDB=1 -DGRN_WITH_BUNDLED_LZ4=ON
# Make it
make \
CC="$CC" \
CXX="$CXX" \
LDFLAGS="-L$MUSL_LIB -Wl,-rpath,$MUSL_LIB" \
CFLAGS="-I$MUSL_INC" \
CXXFLAGS="-I$MUSL_INC" \
CPPFLAGS="-I$MUSL_INC"
I hope this helps someone else out in the future :)
I am trying to set up a cross compiling environment for the Raspberry Pi 3 on my Mac because compiling on the Pi just became to slow.
Following this guide I successfully created a cross compiler using crosstool-ng that is able to compile a simple "Hello World" program that runs on the Pi.
I try to follow the RaspberryPi2EGLFS-Guide on the Qt wiki.
It is written for Ubuntu but that should not make a difference when you have a compiler for your host system, does it?
I created the sysroot and fixed symbolic links as described in the guide, but the configure command for Qt fails.
./configure \
-release \
-opensource -confirm-license \
-make libs \
-opengl es2 \
-device linux-rpi3-g++ \
-sysroot $SYSROOT \
-opensource -confirm-license -make libs \
-prefix /usr/local/qt5pi -extprefix ~/dev/raspi/qt5pi \
-hostprefix ~/dev/raspi/qt5 \
-device-option CROSS_COMPILE=$TOOLCHAIN \
-v
There, $TOOLCHAIN points to the toolchain I compiled and $SYSROOT is the sysroot I set up according to the guide.
But the command fails with a bunch of errors because header files could not be found:
fatal error: sys/cdefs.h: No such file or directory
fatal error: zconf.h: No such file or directory
fatal error: sys/types.h: No such file or directory
Edit 12-14-2016
Apparently the compiler can't determine the cpu architecture:
/Volumes/xtools/armv8-rpi3-linux-gnueabihf/lib/gcc/armv8-rpi3-linux-gnueabihf/5.2.0/../../../../armv8-rpi3-linux-gnueabihf/bin/ld.gold: error: /Volumes/xtools/armv8-rpi3-linux-gnueabihf/armv8-rpi3-linux-gnueabihf/sysroot/usr/lib/crti.o: unknown CPU architecture
From my (limited) understanding, these headers should apear somewhere in $SYSROOT.
I have checked my sysroot, the missing headers a located in $SYSROOT/usr/include/arm-arm-linux-gnueabihf/.
I created a symlink from there to $SYSROOT/sys but that did not work either.
Am I missing something?
Other threads suggest installing g++-multilib on the host system, but there is no multlib-equivalent on macOS.
Building GCC (latest revision) on OS X 10.11.1 here, using the command line:
../gccx/configure --with-gmp="/opt/local" --with-mpfr="/opt/local" \
--with-mpc="/opt/local" --with-libiconv-prefix="/opt/local" --with-pkgversion="GCCX" \
--program-transform-name='s/^gcc$/gccx/; s/^g++$/g++x/' --enable-languages=c
Followed build instructions exactly, and getting this error:
g++ -std=gnu++98 -g -DIN_GCC -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -Wl,-no_pie -o build/genmatch \
build/genmatch.o ../build-x86_64-apple-darwin15.0.0/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../build-x86_64-apple-darwin15.0.0/libiberty/libiberty.a Undefined symbols for architecture x86_64: "_iconv", referenced from:
convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o)
(maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv ) "_iconv_close", referenced from:
__cpp_destroy_iconv in libcpp.a(charset.o)
__cpp_convert_input in libcpp.a(charset.o) "_iconv_open", referenced from:
init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/genmatch] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make:
*** [all] Error 2
(A complete log is available at https://gist.github.com/3cb5d044533e657f4add.)
After investigating gcc/Makefile, it seems that the BUILD_CPPLIB variable does not include $(LIBICONV), since it is in a stage1 bootstrap at the time of the error. The relevant section is preceded by
# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled. For stage2+ use the host library and
# its dependencies.
Yet clearly the stage1 build of build/genmatch is referencing libcpp, which uses symbols from libiconv. So something is amiss here.
How can I fix it?
General discussion
Building GCC on Mac OS X is an occasionally fraught process. I've had various issues with various versions of GCC and various versions of Mac OS X over the years. You can see an earlier explanation of what I did in Install GCC on Mac OS X — that was for building GCC 4.8.x on Mavericks 10.9.x (or possibly Mountain Lion 10.8.x); it also reports success building GCC 4.9.0 on Mavericks 10.9.x, but failure to do so on Yosemite 10.10.x.
This is an updated recipe for building GCC 5.2.0 on Mac OS X 10.11.1 El Capitan.
It starts off using XCode 7.1.1 — I don't know which other versions of XCode are OK.
Note that El Capitan has a feature SIP (System Integrity Protection) that was not in Yosemite and earlier versions. This means you cannot create arbitrary directories under /usr any more. I used to install in /usr/gcc/vX.Y.Z; that is no longer permitted in El Capitan. One major change, therefore, is that I now install in /opt/gcc/v.X.Y.Z.
I've found that having DYLD_LIBRARY_PATH set is problematic — especially on El Capitan. In a major break from the past, I'm now not setting that at all. Note that the scripts unset it. Note too that the script explicitly sets the phase 1 compilers CC and CXX to /usr/bin/clang and /usr/bin/clang++ respectively (the XCode compilers). The current versions of GCC require a capable C++ compiler instead of (or as well as) a C compiler.
I have occasionally had problems with libiconv, but at the moment I've evaded them by not having my own version installed. Similarly, I've occasionally had problems with some awk scripts in the GCC source. I had to hack it/them to get it to work OK. However, with release copy of GCC 5.2.0 source, I seem to be able to build directly out of the box.
If you've only got a single disk partition, this next point isn't crucial. If you have multiple disks, either make sure the target directory does not exist or ensure that its name is exactly what you want. On the machines at work (not Macs but Linux machines, etc), I still use /usr/gcc/vX.Y.Z as the 'official' install location, but the software ends up in some arbitrary file system where there's enough space, such as /work4/gcc, and eventually there is a symlink such that /usr/gcc/vX.Y.Z gets to /work4/gcc/vX.Y.Z. However, it is crucial that /work4/gcc/vX.Y.Z does not exist while GCC is being compiled because it will resolve the name via realpath() or its equivalent and embed /work4/gcc/vX.Y.Z into the binaries, rather than the neutral name /usr/gcc/vX.Y.Z. This limits the portability of the installation; any other machine that it is moved to has to have a directory /work4/gcc/vX.Y.Z, even though you asked to install it in /usr/gcc/vX.Y.Z.
Compiling GCC 5.2.0 on Mac OS X 10.11.1 with XCode 7.1.1
I had to work with down-versions of both GMP (5.1.3 instead of 6.0.0a) and ISL (0.14 instead of 0.15). The builds for the later versions both caused me trouble.
Note that I put the library code for GMP, MPC, MPFR, ISL and Cloog (see the GCC pre-requisites) in the GCC source directory so that GCC builds its own versions of these libraries. I've found that its the simplest way to ensure that GCC locates these libraries correctly.
Target directory: /opt/gcc/v5.2.0
Build time was about 2h 15m on a 17" MacBook Pro (early 2011) running Intel Core i7 at 2.3 GHz, with 16 GiB 1333 MHz DDR3 main memory, and a 750 GB 5400 rpm hard disk drive. The source occupies about 850 MiB; the build tree ends up at about 4.6 GiB — you need plenty of disk space. The installed code ends up at about 420 MiB.
Script used — extract-gcc-5.2.0.sh
#!/bin/bash
unset DYLD_LIBRARY_PATH
TAR=tar
VER_NUM=5.2.0
GCC_VER=gcc-${VER_NUM}
TGT_BASE=/opt/gcc
TGT_DIR=${TGT_BASE}/v${VER_NUM}
CC=/usr/bin/clang
CXX=/usr/bin/clang++
extract() {
echo "Extract $1"
$TAR -xf $1
}
if [ ! -d "$GCC_VER" ]
then extract ${GCC_VER}.tar.bz2 || exit 1
fi
(
cd ${GCC_VER} || exit
nbncl <<EOF |
cloog 0.18.1 tar.gz
gmp 5.1.3 tar.xz
# gmp 6.0.0 tar.lz
isl 0.14 tar.bz2
# isl 0.15 tar.bz2
mpc 1.0.3 tar.gz
mpfr 3.1.3 tar.xz
EOF
while read file vrsn extn
do
tarfile="../$file-$vrsn.$extn"
if [ ! -f "$tarfile" ]
then echo "Cannot find $tarfile" >&2; exit 1;
fi
if [ ! -d "$file-$vrsn" ]
then
(
set -x
extract "$tarfile" &&
ln -s "$file-$vrsn" "$file"
) || exit 1
fi
done
)
if [ $? = 0 ]
then
mkdir ${GCC_VER}-obj
cd ${GCC_VER}-obj
../${GCC_VER}/configure --prefix="${TGT_DIR}" \
CC="${CC}" \
CXX="${CXX}"
make -j8 bootstrap
fi
Script nbncl — non-blank, non-comment lines
#!/usr/bin/env perl
#
# Non-blank, non-comment lines only
use warnings;
use strict;
while (<>)
{
chomp;
s/\s+$//;
s/\s*#.*$//;
print "$_\n" unless /^$/;
}
First, see Jonathan Leffler's very complete answer. I have a few more suggestions here.
The gcc configuration and build process needs to find your system's native header files and C run-time libraries. Newer, clang-based versions of Xcode hide these pretty deeply, and older versions of gcc don't seem to know how to find them. To get gcc 4.6 to build at all, I had to create these symlinks:
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include /usr
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/dylib1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/bundle1.o /usr/local/lib
Your mileage will likely vary slightly: note that those pathnames underneath /Applications/Xcode.app/Contents have various version numbers baked in to them, which are likely to be different on your system.
(If, as Jonathan describes, the newest versions of MacOS don't allow you to put anything in /usr, you might have to create the /usr/include symlink in /usr/local/include, instead, and I suspect that would work, too.)
Also, this is mentioned elsewhere, but it's an unusual requirement, and easy to overlook: do not try to build gcc within its own source tree. Always create a build directory which is a parallel sibling, not a child underneath, of the directory into which you've extracted the gcc sources. That is, do not do this:
tar xzf gcc-x.y.z.tar.bz2
cd gcc-x.y.z # WRONG
mkdir build
cd build
../configure # WRONG
make
Instead, do this:
tar xzf gcc-x.y.z.tar.bz2
mkdir build
cd build
../gcc-x.y.z/configure
make
This is counterintuitive, I know, and it's not the way a lot of other packages work, but it definitely does work for gcc, and it's the recommended way to do it.
Another point: if you discover that your build is failing because you configured it improperly, such that you have to rerun configure with different options, it's safer to delete your entire build directory and start from scratch. The configure and build system sometimes, but it seems not 100% reliably, detects what might need rebuilding in that case. (Deleting and starting over is frustrating, I agree, but again, it can really save time in the long run.)
Finally, if you're trying to build a cross-compiler, see some additional suggestions and commentary at install gcc 4.6.1 on OS X 10.11 .
For what it's worth, MacPorts has ports for all recent versions that should be sufficiently easy for everyone (who knows how to code!) to read who doesn't want to install MacPorts but prefers to install the various dependencies mentioned here some other way.
A slightly tweaked personal version of the port for gcc 6.3.0:
https://github.com/RJVB/macstrop/blob/master/lang/gcc6/Portfile
The reason I mention that one (and post this answer) is that this tweaked version shows how to get G++ to use libc++ instead of libstdc++. That's a prerogative for being able to use G++ as a real replacement for clang++ that can be used without worrying about C++ runtime incompatibilities. This patch has allowed me to use g++ to build KDE (KF5) code and run it against Qt5 and the KF5 frameworks built with various clang compiler versions. (The patch files are in .../gcc6/files .)
Some explanation that might help interpreting the Tcl code of the linked file:
Ignore anything that's specific to $subport == "libgcc".
As you can see, you need gmp, mpc, mpfr and isl (the other dependencies should be of no interest if you're installing on your own).
The configure.args expressions construct the argument list to the configure script, configure.env and build.env add environmental variables for the configure and build (make) commands. Many of the configure options here are to ensure that the build uses dependencies from MacPorts but they'd probably be required too if you want or have to use a location not controlled by SIP and that isn't included in standard PATH definitions (the compiler still ought to work when invoked through a process that resets the path).
The configure and build are done in a build directory that sits next to the source directory, which makes it very easy to start over or just clean up without throwing away the sources.
After the configure step the build is done with "make bootstrap-lean" - which still creates about 1.7Gb of data in that build directory.
I have a problem linking correctly my project. The project is built with CMAKE. Linking seems fine, but at run time an error is thrown.
Here is the command that was used for linking:
$ /usr/bin/clang -Wl,-search_paths_first -Wl,-headerpad_max_install_names \
CMakeFiles/project.dir/src/conf.c.o CMakeFiles/project.dir/src/tun-compat.c.o \
CMakeFiles/project.dir/src/compress.c.o CMakeFiles/project.dir/src/mc.c.o \
CMakeFiles/project.dir/src/hexdump.c.o CMakeFiles/project.dir/src/server.c.o \
CMakeFiles/project.dir/sys/unix/log.c.o CMakeFiles/project.dir/sys/unix/imsg.c.o \
CMakeFiles/project.dir/ sys/unix/imsg-buffer.c.o CMakeFiles/project.dir/sys/unix/toto.c.o \
CMakeFiles/project.dir/sys/unix/toto.c.o CMakeFiles/project.dir/sys/unix/util.c.o \
CMakeFiles/project.dir/sys/unix/conf.c.o CMakeFiles/project.dir/sys/unix/tntsocket.c.o \
-o bin/project/opt/local/lib/libevent_openssl.dylib /opt/local/lib/libevent_core.dylib \
/usr/lib/libz.dylib /opt/local/lib/libyajl.dylib /opt/local/lib/libtapcfg.dylib
The error I get:
$ ./bin/project
dyld: Library not loaded: build/libtapcfg.dylib
Referenced from: /Users/Antoine/project/./bin/project
Reason: image not found
zsh: trace trap ./bin/project
Additional infos:
$ dyldinfo -dylibs bin/projectattributes
dependent dylibs
/opt/local/lib/libevent_openssl-2.0.5.dylib
/opt/local/lib/libevent_core-2.0.5.dylib
/usr/lib/libz.1.dylib
/opt/local/lib/libyajl.2.dylib
build/libtapcfg.dylib
/usr/lib/libSystem.B.dylib
It looks like black magic to me. The linker is able to find the symbols, but end up by changing the path of the library even if I can't see any difference in the way it is handled in the linking command...
The lib location is /opt/local/lib/libtapcfg.dylib
$ ls -lhF /opt/local/lib/libtapcfg.dylib
-rwxr-xr-x 1 root admin 20K 14 jui 18:05 /opt/local/lib/libtapcfg.dylib*
Does the problem maybe come from the lib I am linking to?
The issue is with how you built and installed libtapcfg.
You seem to have copied it from your local directory to /opt/local/lib and thus its file system path does not match what is stored in the library.
Either leave the lib in your local path or when building it tell the linker where it will end up or copy to /usr/local/lib which is hard coded in the linker. See Apple developer's note on dynamic libraries
You should only put things in /opt/local when using macports by means of a port. In this case create a local portfile which does not have to do much and macports standard work will put the correct information in the library to make it work from /opt/local/lib