Программа C ++ компилируется на двух разных машинах. Общая библиотека работает правильно на одном. С другой стороны, методы класса возвращают NULL
Я пытаюсь написать несколько программ, используя библиотеки openbabel, одна из которых — простая программа для извлечения данных из файла sdf. Но одна из функций у меня FormatFromExt не работает. Вызов функции возвращает NULL независимо от того, какие входные параметры я передаю.
OpenBabel::OBFormat *inputFormat = conv.FormatFromExt(argv[1]);
// This method fails, returns NULL ^^
if (!inputFormat || !conv.SetInFormat(inputFormat)) {
char buf[256];
sprintf(buf, "Could not find input format for file: %s", inputFormat);
cerr << buf << endl;
exit(0);
}
Другие методы для этого класса, OBConversion, также возвращают NULL, такие как SetInfFormat, FindFormat а также Read,
Я убедился, что argv [1] действительно содержит путь к входному файлу и что файл имеет допустимое расширение для библиотек openbabel. Я также включаю все необходимые файлы заголовков. На одной машине этот код работает отлично. С другой стороны методы терпят неудачу. Программа отлично компилируется на обоих. Что может вызвать что-то подобное?
Библиотеки openbabel, которые я использую, являются общими объектными файлами.
Решение
Итак, это похоже на неправильную конфигурацию. По сути, он ищет файлы .so и не находит их на удаленной машине.
Итак, давайте посмотрим на два следа, начиная с того места, где они расходятся. Это не сложно найти, так как в основном это конец неудачной трассировки. Сначала давайте посмотрим на тот, который работает:
openat(AT_FDCWD, "/usr/local/lib/openbabel/2.3.2", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
brk(0x1199000) = 0x1199000
getdents(5, /* 112 entries */, 32768) = 4200
getdents(5, /* 0 entries */, 32768) = 0
close(5) = 0
futex(0x7f7fbacf90b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/local/lib/openbabel/2.3.2/castepformat.so", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340.\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=521866, ...}) = 0
mmap(NULL, 2126352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f7fba3db000
mprotect(0x7f7fba3e2000, 2093056, PROT_NONE) = 0
mmap(0x7f7fba5e1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f7fba5e1000
close(5) = 0
mprotect(0x7f7fba5e1000, 4096, PROT_READ) = 0
open("/usr/local/lib/openbabel/2.3.2/xedformat.so", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260'\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=432606, ...}) = 0
mmap(NULL, 2118032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f7fba1d5000
mprotect(0x7f7fba1da000, 2093056, PROT_NONE) = 0
mmap(0x7f7fba3d9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x4000) = 0x7f7fba3d9000
close(5) = 0
mprotect(0x7f7fba3d9000, 4096, PROT_READ) = 0
open("/usr/local/lib/openbabel/2.3.2/PQSformat.so", O_RDONLY|O_CLOEXEC) = 5
Открывает каталог /usr/local/lib/openbabel/2.3.2, а затем читает все записи в нем. Есть записи в 4200 байт. Затем он последовательно загружает кучу файлов .so (разделяемые библиотеки). Это, по-видимому, то, что он нашел в /usr/local/lib/openbabel/2.3.2,
Хорошо, теперь давайте посмотрим на тот, который потерпел неудачу:
open("/tools/cluster/6.2/openbabel/2.3.2/lib/openbabel", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
fcntl(5, F_GETFD) = 0x1 (flags FD_CLOEXEC)
brk(0x1dd6000) = 0x1dd6000
getdents(5, /* 3 entries */, 32768) = 80
getdents(5, /* 0 entries */, 32768) = 0
brk(0x1dce000) = 0x1dce000
close(5) = 0
write(2, "Could not find input format for "..., 76Could not find input format for file: files/Compound_014725001_014750000.sdf) = 76
Открывается вместо /tools/cluster/6.2/openbabel/2.3.2/lib/openbabel, Затем он читает только записи размером 80 байт, предположительно потому, что этот каталог пуст или почти пуст. Затем он немедленно печатает сообщение об ошибке.
Похоже, что конфигурация указывает на неправильный каталог, или этот каталог никогда не заполнялся всеми файлами .so. Обратите внимание, что он нашел Compound_014725001_014750000.sdf хорошо в обоих случаях. Если вы посмотрите несколько строк выше, откуда я начинаю цитировать, вы можете увидеть системные вызовы для этого открытия.
Другие решения