Security Lab



Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
Форум » Для программистов и разработчиков » Системное программирование
Страницы: 1
RSS
Suse, Oracle и C++, кроссплатформенность -- миф или реальность?
 
#1
Это нравится:0Да/0Нет
01.10.2009 00:53:31
Итак, дамы и господа, есть некая проблема.

Предыстрория. Есть либа (.lib @ Win32/64 / .a @ Suse 32/64), которая использует OCCI (Oracle 10.2g). Есть сервис, представляющий собой уровень бизнес-логики, который использует данную либу.
Под Windows (32/64) все компилируется, линкуется, запускается и работает.
Код, как вы понимаете, кроссплатформенный на уровне ifdef для сокетов (в .h), для потоков (.сpp - Win32/pthread) и синхронизации (Win32: CritSect, Posix: pthread_mutex)

Под Linux (OpenSuSe 10.2) возникла очень странная проблема, которую я так и не смог решить онанируя модицифицируя различными способами makefile.
Проблема в следующем:
ldd показывает отсутствие линков на .so библиотеки оракла, при том, что линкер сам по себе находит все unresolved externals.

Компилил на редхате 7.x (наследство =) и OpenSuSe 10.2. Часть конфликтов решается прописываением _нужных_ версий библиотек, однако ld никак не может подхватить либы оракла. И это печально....

Есть идеи?
 
 
 
#2
Это нравится:0Да/0Нет
03.10.2009 21:26:54
как-то очень странно. могу посоветовать посмотреть на cx_ocracle(модуль для python). там аналогичная задача и оно тоже кроссплатформенное.
 
 
 
#3
Это нравится:0Да/0Нет
04.10.2009 12:04:01
Цитата
^rage^ пишет:
python
Я тебя тоже люблю, но это мимо кассы.
Пока что, опытным путем, выяснилось, что почему-то существует конфликт библиотек по версиям (libc, libstdc++, libpthread и т.п.) с либами оракла.
Вариантов пока что много -- так что имеем, хоть и извращенный, но все же секс =)

Основная задача теперь -- перебороть segmentation fault при occi:createEnvironment

OS: SLES 10
orcl: Oracle 10g R2
 
 
 
#4
Это нравится:0Да/0Нет
30.11.2009 05:17:48
Цитата

Проблема в следующем:

ldd показывает отсутствие линков на .so библиотеки оракла, при том, что линкер сам по себе находит все unresolved externals.

Что мешает прописать пути к Oracle библиотекам в переменную окружения LD_LIBRARY_PATH ?
Например так:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/oracle/lib
export LD_LIBRARY_PATH
/path/my_super_program

Кроме того динамический линкер смотрит содержимое файлов /etc/ld.so.conf, /etc/ld.so.conf.d/*.conf
После их изменения (или добавления ещё одного файла) нужно обновить кэш динамического линкера командой ldconfig. Посмотреть есть ли нужная библиотека в кэше можно командой:
ldconfig -p|grep libname.so

Если данные библиотеки нужны ТОЛЬКО одной проге, то IMHO проще сделать скрипт-обёртку, запускающий твою программу.
С ходу на ум приходит два варианта:

1) как описано выше (с переменной LD_LIBRARY_PATH)

2) использовать переменную LD_PRELOAD
--- cut ---
#!/bin/sh
env LD_PRELOAD=/opt/path/libname.so /path/my_super_program
--- cut ---



Цитата

Компилил на редхате 7.x (наследство =) и OpenSuSe 10.2. Часть конфликтов решается прописываением _нужных_ версий библиотек, однако ld никак не может подхватить либы оракла. И это печально....
Есть идеи?

Обычно это лечится прописыванием правильных путей к библиотекам.
Подробности  (про переменные LD_LIBRARY_PATH и LD_PRELOAD) см. man ld.so
Там много интересного на эту тему в разделе ENVIRONMENT.
 
 
 
#5
Это нравится:0Да/0Нет
01.12.2009 05:28:36
В догонку на тему "segmentation faul":
Как ставился Oracle ?
Путём переноса уже установленого экземпляра с работающей системы или была нормальная инсталяция "с нуля" ?

Часто встречал, что после копирования $ORACLE_HOME на другую машину забывают выполнить следующие вещи:

1) установить переменные окружения ORACLE_HOME, NLS_LANG, ORACLE_SID, LD_LIBRARY_PATH, PATH.
Обычно значения имеют вид:

ORACLE_HOME=/u01/oracle/9.2.0.1 # или куда там всё поставлено
NLS_LANG=RUSSIAN_CIS.AL32UTF8 # Для UTF-8 кодировки
ORACLE_SID=prod # Имя экзкмпляра базы
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
PATH=$PATH:$ORACLE_HOME/bin

И нужно не забыть строку:
export ORACLE_HOME NLS_LANG ORACLE_SID LD_LIBRARY_PATH PATH

2) выполнить перелинковку бинарников.
В случае если система откуда переносят и система на которую переносят абсолютно идентичны (имеют одинаковые версии библиотек, gcc) - это не нужно.
Перелинковка выполняется командами:
cd $ORACLE_HOME/bin
./relink all

Кроме того я бы рекомендовал выполнять перелинковку после обновления glibc, gcc, glib, glib2. Пару раз встречал различные "чудеса" после их обновления без перелинковки.
 
 
 
Страницы: 1
Читают тему