Подключение к VirtualBox физического жесткого диска

Вы можете создать виртуальную машину, работающую со специальным *.vmdk-диском, в действительности напрямую отображаемом в реальный жесткий диск, в том числе внешний.

Так создается описанная связь (предполагается, что вы хотите создать *.vmdk-диск с именем usb-hdd320 и соединить его с пустым физическим диском /dev/sdc, и все происходит в ОС семейства Linux):

# cd ~/VirtualBox\ VMs
# sudo vboxmanage internalcommands createrawvmdk -filename usb-hdd320.vmdk -rawdisk /dev/sdc

Вы должны получить сообщение "RAW host disk access VMDK file usb-hdd320.vmdk created successfully", если все прошло хорошо. Далее необходимо создать виртуальную машину с именем, например, minilab, для работы с жестким диском через *.vmdk файл:

# sudo vboxmanage createvm --name minilab --ostype Ubuntu --register
# sudo vboxmanage modifyvm minilab --memory 512
# sudo vboxmanage storagectl minilab --name "IDE Controller" --add ide
# sudo vboxmanage storageattach minilab --storagectl "IDE Controller"--port=0 --device=0 --type hdd --medium ~/VirtualBox\ VMs/usb-hdd320.vmdk

Если вы хотите подкючить к ней iso-образ инсталляционного диска с именем, скажем, installation_cd.iso, то по образу и подобию подключения жесткого диска можете сделать следующее:

# sudo vboxmanage storageattach minilab --storagectl "IDE Controller" --port=0 --device=1 --type dvddrive --medium ~/VirtualBox\ VMs/installation_cd.iso

Запускается виртуальная машина minilab так:

# sudo vboxmanage startvm minilab

Можно провести сколь угодно сложную работу жеским диском в виртуальной машине, затем подключить его физически и загрузиться.

Qt & multiple definition

QГрабля#5


При инстанцировании шаблонов внутри классов, использующих мета-объектную систему Qt, а также в ряде других ситуаций при использовании этой библиотеки (на практике особенно часто - при создании Unit-тестов силами QTestLib) возможно возникновение ошибки линковки multiple definition. Связано это с тем, что moc парсит заголовочные файлы и для всех файлов, содержащих класс с макросом Q_OBJECT генерирует *.cpp-файл с необходимым для функционирования мета-объектной системы Qt кодом. Такой файл становится отдельной единицей компиляции, и если в нем, как пример, инстанцируется какой-либо шаблон, то он, согласно правилам компиляции шаблонов C++, полностью включается в генерируемый объектный файл. Врочем, ровно то же происходит при инстанцировании такого шаблона в любом другом *.cpp файле, например, содержащем main(). В итоге в ходе линковки один и тот же шаблон обнаруживается сразу в нескольких объектных файлах, что и приводит к возникновению описанной выше ошибки.

Поправить ситуацию можно несколькими способами. Можно все методы шаблона сделать
inline-овыми (см. описание похожей ситуации), можно модифицировать сборку Qt-проекта вручную так, чтобы генерируемый moc'ом файл просто включался в файл, по которому он был сгенерирован (именно это в простых случаях автоматизировано выполняет этот скрипт (см. замечания)) Либо можно позволить линковщику самостоятельно разрешать такие конфликты, просто выбирая первое из многочисленных определений (ключ -z muldefs для *nix-линковщика ld) Интегрировать нужные ключи можно автоматически в Makefile с помощью этого скрипта (см. описание), либо просто ключив в *.pro-файл строку вида:

QMAKE_LFLAGS += -z muldefs

Этим сообщением я начну небольшую серию постов про грабли, с которыми, вероятно, столкнется каждый начинающий пользователь фреймворка Qt. Тривиальных вещей здесь не будет, они прекрасно изложены в первую очередь в документации самого Qt, которая вряд ли имеет равных себе по качеству, охвату и незанудности.

QГрабля#1


Если в приватной секции определения класса, использующего метаобъектную систему Qt, вы забыли указать макрос Q_OBJECT, а затем исправили свою оплошность, то вы вполне можете снова (и снова, и снова...) получить ошибку компиляции со словами в духе "undefined reference" и "vtable of <YourClass>" в строках клиентского кода, использующих в вашем классе дополнительные возможности наследников QObject (сигналы и слоты, свойства, возможности интроспекции).
Подобное может произойти в том случае, если ранее ваш класс, определенный без макроса Q_OBJECT уже успешно компилировался (то есть, дополнительные возможности не использовались) - и в папке сборки уже лежит Makefile, сгенерированный по *.pro-файлу утилитой qmake. Дело в том, что даже после внесенных исправлений, пересборка проекта заключается в вызове make, подхватывающей старый Makefile, который не вызывает MOC для файлов вашего класса (так что даже make clean не поможет).

Решение


Вручную удалите Makefile в директории сборки проекта и пересоберите его.

Так же полезно завести в директории ~/bin файлик с содержимым вроде

#!/bin/sh
if [ -e "Makefile" ]
then
    make clean
    rm Makefile
fi
qmake -project
qmake
make

(не забудьте сделать chmod +x <имя файла> и убедиться в том, что ~/bin есть в переменной окружения PATH (иначе можно ее туда добавить, дописав в ~/.profile строку

PATH="$HOME/bin:$PATH" ))

... и затем собирать проекты вызовом этого скрипта. У меня это выглядит так:

qqmake

Мучает info?

Когда-нибудь Emacs придется освоить, ну а пока - перенаправляйте:

user@host cwd$ info something | less