On 11.12.2012 12:29, Jean-Louis 'Hans' Fuchs wrote:
Hello
We have a build breaker on solaris 11/Sparc tag 341, we suppose that
we have to add all indirectely linked libraries to the call below.
Solaris seems like OS X not to support indirect linking.
/opt/solarisstudio12.3//bin/CC -Bdynamic -z text -G
'-R$ORIGIN:$ORIGIN/../ure-link/lib' -L$S/solenv/unxsols4/lib
-L$O/lib -L$S/solenv/unxsols4/lib -L$S/solenv/unxsols4/libsolaris.2.6
-L/lib -L/usr/lib -L/usr/local/lib -L/usr/dt/lib -L/usr/openwin/lib
-L/usr/jdk/instances/jdk1.6.0/lib
-L/usr/jdk/instances/jdk1.6.0/jre/lib/sparc
-L/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/xawt
-L/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/native_threads -L/usr/lib
-temp=/tmp -w -mt -Bdirect -z defs -z combreloc -norunpath -PIC
-library=no%Cstd -lcomphelpC52 -luno_cppu -luno_cppuhelperC52 -lfwe
-li18nisolang1C52 -luno_sal -lsax -lsb -lsot -lstlport_sunpro -lsvl
-lsvt -ltk -ltl -lucbhelper4C52 -lutl -lvcl -lvos3C52 -lxml2 -lsfx
-lgtk-x11-2.0 -lsecdb -ltsol -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0
-lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor
-lXcomposite -lXdamage -lgio-2.0 -lXfixes -lcairo -lX11 -lpango-1.0
-lfreetype -lfontconfig -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 -lm
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lglib-2.0
$W/CxxObject/sfx2/source/appl/shutdowniconunx.o -o
$W/LinkTarget/Library/libqstart_gtk.so
We wanted to test this call with different linker settings. But the
call has many variables: $ORIGIN/$W/$S.
I don't know about $ORIGIN but $R, $S, $O, $W are variables that are
used to make command lines shorter and more readable.
They are created on the fly when an external command is called. Make
will create a command line like this (from building sw/ on Windows):
R=/cygdrive/c/source/sidebar/git && S=$R/main &&
O=$S/solver/350/wntmsci12.pro && W=$O/workdir && mkdir -p
$W/Dep/LinkTarget/Library/ && RESPONSEFILE=C:/tmp/gbuild.nWG7fb && cat
${RESPONSEFILE} /dev/null | xargs -n 200 cat >
$W/Dep/LinkTarget/Library/ivbaswobj.lib.d && rm -f ${RESPONSEFILE}
In order to continue with our investigation, we have to be either:
1. able to get the contents of this variables
2. find the definition of LIBS or similar for this project
- The makefile seems to part of complex build system, that doesn't use
make in a verbose way. Is there any documentation for gbuild.mk based
makefiles?
There is documentation (Ariel gave a link in another mail) but that is
outdated.
I can not help you with your actual problem but I can give a (very
short) introduction to gbuild.
gbuild uses GNU make to define its own domain specific language. Macro
names try to provide some object orientation. Take sw/Library_sw.mk as
an example. There you can find the lines
$(eval $(call gb_Library_add_exception_objects,sw,\
sw/source/core/SwNumberTree/SwNodeNum \
... many more lines
sw/source/ui/wrtsh/wrtundo \
))
This calls the "function" gb_Library_add_exception_objects on the object
"sw" and the arguments
sw/source/core/SwNumberTree/SwNodeNum to sw/source/ui/wrtsh/wrtundo.
The function name gb_Library_add_exception_objects tells you that it is
a gbuild method (gb_) defined for class 'Library'. The actual method
name is 'add_exception_objects'.
It adds the (partial) file names as C++ source files that are to be
compiled with exception support to the 'sw' library.
In main/solver/gbuild there is a rough association of class names to
file names. Methods defined for class 'Library' can be found in
Library.mk. Some are defined in LinkTarget.mk (LinkTarget is the base
'class' of Library).
Note that macro names are sometimes created dynamically so that grep or
OpenGrok will not find them. In Helper.mk there is for example the macro
define gb_Helper_make_clean_target
gb_$(1)_get_clean_target = $(WORKDIR)/Clean/$(1)/$$(1)
endef
that, for sw, would define gb_sw_get_clean_target.
-Andre
PS: I have been working in my spare time on re-implementing gbuild in
Java. I thought (and now have proof) that it were easier to implement
file dependencies in Java than to implement object orientation in make.
I can already build about 90% of sw/. And even if this experiment will
never be used to build OpenOffice, it helped me to understand gbuild
much better than before. I may be able to answer some detail questions
about gbuild.
We found the command above using
cd main/sfx2
/usr/bin/gmake -r -j1
which also gives us an error like this:
Undefined symbol void*__Crun::ex_alloc(unsigned)
first referenced in file
/home/oobuild/aoo-build-341/ooo/main/solver/341/unxsols4.pro/workdir/CxxObject/sfx2/source/appl/shutdowniconunx.o
(symbol belongs to implicit dependency /usr/lib/libCrun.so.1) ...
...
all of the missing symbols are in implicit dependencies.
Best,
Jean-Louis Fuchs
