# Build question ( .so...)



## jb_fvwm2 (Feb 24, 2013)

Oftentimes during a port build, "in .so... undefined reference to [foo bar].."
Slight chance someone knows, when such an error occurs, if there is some command which would show which of the (say, less than a quarter of the build dependencies) were referenced in the building of that particular .so; maybe such command (if it exists) would enable the rebuild of just one or two dependencies, fixing the build for that port in a shorter amount of time than may otherwise be needed.
Or some wrapper for the build process emits such information as the build transpires... maybe even a port some persons are now using in that way or something similar.


----------



## derekschrock (Feb 25, 2013)

Reading /usr/ports/UPDATING normally doesn't put you into these types of situations.


----------



## jb_fvwm2 (Feb 25, 2013)

UPDATING typically applies only to some of these cases; I catch 99 percent of those reasons beforehand, even run X applications out of X to debug errors that otherwise not might be easily fixed. This, however, applies to situations where a single port (or small number of them) throws a specific build error and has, typically, no recent UPDATING entries.


----------



## kpa (Feb 25, 2013)

I did not quite get what you're asking but I'll try to answer.

Dynamic load libraries that have been linked into final loadable (.so files) modules can not be edited afterwards. The dependencies to external symbols (provided by other dynamic libraries) are in effect "set to stone". Fixing any problems with the symbols requires a full recompilation of the module.


----------



## jb_fvwm2 (Feb 25, 2013)

I was thinking more or less, if there existed a wrapper for the build which would be equivalent to a .....  --Dshow_only_those_dependencies_which_comprise_the_latest.so_
... so when it halts, only a few of the many dependencies are known, in case it is a dependency problem and not a source code problem, per se.


----------

