From: <iv...@cv...> - 2013-01-30 16:51:25
|
Quoting Petr Van?k <pe...@ya...>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi all, > > I'd like to inform you that we are screwed on mac platform for now. > > issues: > > - - oracle instant client crashes any app on mac > 10.6. So the latest 2 > versions of OS X are unusable. > > https://trac.macports.org/ticket/31521 > > fix: impossible until Oracle won't release new client. > fox estimation: never. > workaround: to build everything as i386. We do it in macports. But it's > pain in the ass for any other user. It requires i386 version of all > libraries etc. > me: disappoint. > Hmm its sad. This is the reason why created trotl library even if there was C++ library (occi) available. It is(was) compiled using some older version of g++ which uses incompatible ABI. Any exception thrown from OCCI causes SEGFAULT - it can not be caught in code compiled using g++ >= 4.3 I've just checked metalink is the problem is described as Oracle bug: Bug 13603934 : OCI APPLICATION USING INSTANT CLIENT CRASHES ON OS X LION, 64-BIT -- cite metalink -- Key Symptoms/Summary/Rediscovery: OCI Instant Client Crashes on OS X Lion 64 bit. Explain why this is not a bug: This particular OS release oracle db client combination is currently not certified and hence not currently supported. From Oracle Development: 10.2 is not certified to run on Lion. We are working on a 11gr2 client to support Lion and is expected to be available mid CY2012. -- end cite -- It looks like there is something wrong with the calendar. > > - - tora3 is not compilable on mac. Well, the exe is but libraries > cannot be linked. There are some symbols exported from bundle executable > but all results in stuff like this (building without oracle in 64bit mode): > > Linking CXX shared library ../../src/libparsing.dylib > cd /Users/pvanek/oss/tora/build-tora3/extlibs/parsing && > /opt/local/bin/cmake -E cmake_link_script > CMakeFiles/parsing.dir/link.txt --verbose=1 > /usr/bin/c++ -dynamiclib -Wl,-headerpad_max_install_names -o > ../../src/libparsing.dylib -install_name > /Users/pvanek/oss/tora/build-tora3/src/libparsing.dylib > CMakeFiles/parsing.dir/error_handler.c.o > CMakeFiles/parsing.dir/OraclePLSQLLexer.c.o > CMakeFiles/parsing.dir/OraclePLSQLParser.c.o > CMakeFiles/parsing.dir/OracleSQLLexer.c.o > CMakeFiles/parsing.dir/OracleSQLParser.c.o > CMakeFiles/parsing.dir/tplsqlparseoracle.cpp.o > CMakeFiles/parsing.dir/tsqllexeroracle.cpp.o > CMakeFiles/parsing.dir/tsqlparseoracle.cpp.o > /opt/local/lib/libQtGui.dylib /opt/local/lib/libQtXml.dylib > /opt/local/lib/libQtSql.dylib /opt/local/lib/libQtNetwork.dylib > /opt/local/lib/libQtCore.dylib ../../src/libantlr3c.dylib > Undefined symbols for architecture x86_64: > "SQLParser::Statement::translateAlias(QString const&, SQLParser::Token > const*)", referenced from: > SQLParser::OracleSQLStatement::scanTree(SQLParser::ObjectCache*, > QString const&) in tsqlparseoracle.cpp.o > > I talked about it with Ivan. Rest of main platforms (Win/Lin) works > fine. Can anybody (Mike) look at it, please? Because it looks like I'm > in some dead end... > > me: crying in the corner. > > Unfortunatley I do not have access to any Mac box. The library uses so-called weak symbols. The symbol is either undefined or wekly-defined in the library itsef, but is present in the main application. I spend ages till I made it working on Linux and Win. Especially the Windows port was quite hard. If it will not work on Mac I'm about to gave it up. Lately I discovered that QT itself has similar functionality. See: http://doc.qt.digia.com/qt/plugins-howto.html So possibly I can rewrite it into QT plugins, but I did not test it yet. So I'm not 100% sure I can achieve the same functionality. The main goal is to have the main binary not dependent on libclntsh.so. Ivan PS: I can send a minimalistic example of mine plugin concept. (Tree .cpp files, one Makefile, no dependencies). ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |