Статические и общие конфликты символа библиотеки?
У меня есть проект, продолжающий работать, это использует FreeImage и openCV, в настоящее время мы используем поддержку jpeg со стороны обоих из них (я работаю для фиксации этого, но на данный момент это получено для пребывания). Во всяком случае FreeImage компилирует libjpeg 7.0 в свои статические библиотеки, и highgui библиотека openCV связывает его в как общая библиотека (в моей системе, Ubuntu 9, мне установили libjpeg 6.2).
Они связываются в заключительную библиотеку, которую это используется для соединения в различные программы, обертки Java, и т.д. Все это хорошо работает, никакие конфликты символа или что-либо в течение времени компиляции/ссылки. Однако, когда я иду для открытия изображения с помощью функции openCV cvLoadImage, это умирает при чтении заголовка, скорее всего, из-за различий между заголовками в 6,2 и 7.0.
Если я удаляю связь с FreeImage (и закомментируйте код, который требует его), вызовы openCV начинают работать снова, таким образом, ясно статические libjpeg символы от FreeImage конфликтуют с символами, которые были бы загружены из совместно использованной библиотеки libjpeg. То, что я не могу выяснить, - то, почему мой компилятор не бросает ошибку во время соединения из-за двух наборов libjpeg символов. Кроме того, я попытался заменить jpeglib.h заголовок своей системы 7,0 версиями временно, чтобы видеть, синхронизировал ли openCV, скомпилированный с этим затем, с символами, которые freeimage приносит к таблице, напрасно это кажется.
Наконец я поместил printf в jpeg_read_header в libjpeg, который freeimage компилирует и восстановил его, чтобы видеть, использует ли openCV freeimage libjpeg определение. Это не распечатало так, я должен принять нет.
Таким образом, я предполагаю, что мои вопросы
1) Почему не делает соединения статического libjpeg, и общий libjpeg генерируют соединение ошибок, должных копировать символы?
2) Кто-либо знает, почему эти две вещи конфликтуют друг с другом?
Править: Компиляция openCV в режиме отладки и затем в регулярном режиме снова, кажется, пробила что-то свободное и заставила его работать снова, никакая идея, что продолжается.
3 ответа
RVO именно это -- возвращает оптимизацию значений. В большинстве компиляторов сегодня этот параметр включен по умолчанию. Однако передача аргумента не возвращает значение. Вы, возможно, не можете ожидать, что одна оптимизация будет вписываться везде.
Условия создания копии четко определены в пункте 3 пункта 15 статьи 12.8.
, когда временный объект класса имеет не был связан со ссылкой (12.2) будет скопирован в объект класса с того же cv-неквалифицированного типа , копия операция может быть опущена построение временного объекта непосредственно в цель пропущенная копия
[акцент мой]
LHS Foo является const квалифицированным, временное не ИМХО, это исключает возможность копирования-удаления.
Я слышал о 2 способах сделать это. Во-первых:
from win32com.shell import shell
shell.SHGetSpecialFolderPath(0,shellcon.CSIDL_COMMON_STARTMENU)
Во-вторых, использование объекта WScript.Shell (source: http ://www.mail-archive.com/python-win32 @ python.org/msg00992.html ):
import win32com.client
objShell = win32com.client.Dispatch("WScript.Shell")
allUserProgramsMenu = objShell.SpecialFolders("AllUsersPrograms")
userMenu = objShell.SpecialFolders("StartMenu")
Другой источник: http://blogs.msdn.com/saveenr/archive/2005/12/28/creating-a-start-menu-shortcut-with-powershell-and-python.aspx
-121--4222932-Это как
Статические библиотеки компилируются в, динамические библиотеки загружаются во время выполнения, но только те символы, которые отсутствуют (я думаю) вы можете скомпилировать общие библиотеки в, и тогда вы, вероятно, получите конфликт символов.
поэтому opencv использует символы, которые компилируются в, поскольку они уже присутствуют, а не из динамических библиотек. вы в конечном итоге используете статические символы, возможно, с различными сигнатурами, из проспективы opencv.
Вообще говоря, компоновщик нормально передает несколько библиотек, которые разрешают один и тот же символ (символы). Он просто использует первый найденный. Порядок библиотек в командной строке компоновщика определит, какая из них «выиграет».
Это, кстати, НЕ относится к объектным файлам. Каждый компоновщик, который я когда-либо использовал, предполагает, что вы хотите, чтобы использовал все указанные вами объекты, и будет жаловаться, если несколько объектов имеют одинаковый символ.
Вам нужно изменить опции связывания, чтобы экспортировать только те символы, которые вы хотите, тогда все конфликтующие символы будут скрыты внутри статического связывания, и тогда конфликтов не будет. По умолчанию экспортируются все символы, вот в чем проблема. См. эту ссылку: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html