Ticket #3166 (reopened defect)

Opened 5 years ago

Last modified 5 years ago

build fails if INST_DLL and INST_BIN point to different paths

Reported by: rogutes Owned by:
Priority: major Component: other
Version: VirtualBox 2.1.2 Keywords: install
Cc: Guest type: other
Host type: other


It would greatly ease packaging of virtualbox-ose, if one could build with, e.g.

$ kmk PATH_OUT="/staging_dir" INST_BIN=usr/bin/ INST_DLL=usr/lib/ INST_SYS=usr/lib/ INST_LIB=usr/lib/obj/ INST_SDK=usr/lib/sdk/

and it almost works, but build (uninformatively) fails whenever INST_BIN and INST_DLL point to different directories. Since other INST_* variables work, perhaps these could also be fixed?

On a similar note, should the compontents/ directory really go to INST_BIN and not to INST_LIB or smth.?

Change History

comment:1 Changed 5 years ago by frank

  • Status changed from new to closed
  • Resolution set to wontfix

Please don't change these variables. To change the target directory for the compiled binary, please have a look at the file debian/LocalConfig.kmk, especially the *PATH* variables at the end of that file. Copy that file one directory up and the directories should fit.

comment:2 Changed 5 years ago by rogutes

  • Status changed from closed to reopened
  • Resolution wontfix deleted

The problem is not the target directory - *PATH* variables work fine for this indeed.

The problem is the actual installation of files to the target directory (aka 'make install' step from autotools). Packaging for debian distributions isn't a problem, because you provide the needed scripts, but packagers for other distribution have to cherry-pick required files from PATH_OUT and put them to the corresponding directories (mostly /usr/bin, /usr/lib).

Doing this once is not that hard, but packagers have to manually check for changes with each new release of VirtualBox OSE, to avoid missing files.

When I checked for a more general way to do this, I've found that the INST_* variables mostly do the job. But since you said that packagers shouldn't touch them, perhaps my report could be (de/pro)moted to a request for a 'make install' step?

comment:3 Changed 5 years ago by frank

I'm not sure if you understood me. Did you actually have a look at debian/LocalConfig.kmk? Note VBOX_PATH_APP_PRIVATE, VBOX_PATH_APP_DOCS, VBOX_PATH_SHARED_LIBS and VBOX_PATH_APP_PRIVATE_ARCH. IMO it does not make sense to put the VirtualBox .so libraries into /usr/lib because these libraries will not be used by any other application. Therefore the proposed place is /usr/lib/virtualbox.

Again, please don't modify the INST_* variables but modify the variables which you can find in debian/LocalConfig.kmk.

comment:4 Changed 5 years ago by rogutes

Yes, we are mis-communicating somewhere. It is clear now that I shouldn't be touching the INST_* variables, and my initial report is wrong. Also, I might be missunderstanding something obvious... But let's try a shell language:

cd VirtualBox-2.1.2_OSE
cp debian/LocalConfig.kmk .
cd out/linux.x86/release

After successfully running this I want to package VirtualBox for my distribution of choice, thus I have to manually move many files from bin/*, lib/* directories, e.g.

mv bin/*.so $(prefix)/usr/lib/virtualbox/
mv bin/VBoxSDL $(prefix)/usr/bin/

and then prepare a package from my $(prefix) staging dir.

Now I believe that moving the files to my staging dir should be handled by a scriptlet prepared by the developers, because they know best which files are required and which not. Currently, the debian/rules script does this, but it is obviously only useful for debian based distributions. What about other distributions? What about a step similar to make install from autotools?


comment:5 Changed 5 years ago by frank

Right, that step is still necessary and I think we should add some generic Makefile target.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use