Well I'm actually trying to link against the object files *.o, this is working fine for me in Debian, I've successfully created both a 32 bit and a 64 bit .so
g++ -I../common -I../../apps/support -I../../apps/crypto/ -Wall -Wno- uninitialized -fvisibility=hidden -fPIC -m32 -O2 -DNDEBUG -shared - dynamiclib -o ../../lib/Mac-x86-32-gcc/libsomething.dylib ../../apps/ crypto/*.o *.o On linux my options are the same, minus -dynamiclib and with -Wl,--gc- sections (which apple's GCC doesn't seem to recognize as a valid option) On Aug 12, 6:22 pm, Mouse <[email protected]> wrote: > Well, perhaps you should check how you compile & link your program. > There's no difference (except for some linker parameters that work on > Linux but not on Mac OS X). All my test-programs (some use ECIES, some > use RSA) compiled and worked smoothly on Snow Leopard. > > Here are my settings: > # GNUmakefile > CXXFLAGS = -DNDEBUG -g -O2 > #CXXFLAGS = -g > # -fPIC is supported. Please report any breakage of -fPIC as a bug. > CXXFLAGS += -fPIC > # the following options reduce code size, but breaks link or makes link > # very slow on some systems > CXXFLAGS += -ffunction-sections -fdata-sections > # the following does not work on Mac OS X as linker doesn't grok > --gc-sections > # LDFLAGS += -Wl,--gc-sections > ARFLAGS = -cr # ar needs the dash on OpenBSD > RANLIB = ranlib > > Everything else is standard. > > Did you install the library to where your application building process > can find it? Did you specify the library to link with? In my case it > worked fine with both shared and static Crypto++ libraries (I've built > both). -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
