| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 27.1 | Re: shared library makefile conventions | SMURF::FILTER | Automatic Posting Software - send mail/comments to flume::puck | Mon May 10 1993 16:00 | 17 |
| Date Of Receipt: 10-MAY-1993 14:52:11.20
From: KRISIS::sandeep "Sandeep Shah USSG"
To: [email protected], [email protected]
CC: [email protected]
Subj: Re: shared library makefile conventions
Ok Jim, I admit to the shortcut (inspired from some other shared library
Makefile in the pool). The problem is that these (libtli.so and libxti.so)
were (and still are) built in a completely different build environment and then
overlaid with the DECnet/OSI layered product.
So "Buildhelp" gurus, can you point me to the right direction for the makefile.
Thanks
sandeep
|
| 27.2 | RE: shared library makefile conventions | SMURF::FILTER | Automatic Posting Software - send mail/comments to flume::puck | Mon May 10 1993 16:35 | 62 |
| Date Of Receipt: 10-MAY-1993 15:33:42.94
From: FLUME::decwet::peterson
To: flume::sandeep
CC: flume::buildhelp, flume::sue
Subj: RE: shared library makefile conventions
You can't use .a libraries to build .so libraries when both are exported
because the shared library export pass occurs before the static library export
pass. You can do it if no other application (or shared library) links with the
shared library, because then the shared library is built in the last pass,
and you would still export the static library (because it was used to link the
shared library).
The reason why the passes are organized this way (and the reason OSF makefiles
compile the same modules twice) is that OSF's compilation system required shared
library modules to be compiled differently from other object modules. This
isn't true of the ALPHA compilation system, and so you might improve the build
time considerably by doing away with the double compilation.
The simplest way for doing this might be to compile the objects directly in the
shared library directoy (see the /usr/shlib/libc/Makefile), and then use those
objects to build the static library by setting VPATH to the shared library
directory). (I'm assuming that the shared library rule does not remove the
objects, but I could be wrong about that). The alternative is to switch the
ordering of the export phases so that static libraries are built before shared
libraries.
--Kim
=========================================================================
From: FLUME::jmcg "Jim McGinness" 10-MAY-1993 11:44:00.22
To: flume::sandeep
CC: flume::buildhelp
Subj: shared library makefile conventions
Sandeep,
The two Makefiles you submitted for usr/shlib/libtli.so and libxti.so show
a failure in sandbox builds, at least in part because of what I think may
be considered an illicit shortcut. Your rule for building the shared libs
looks like:
libtli.so:
echo ${LIBTLISO}
cp -p ${LIBTLISO}/libtli.a .
${_LD_} ${_SHLDFLAGS_} -o [email protected] -all libtli.a ${_LIBS_}
${MV} [email protected] $@
${RM} libtli.a
This fails in PASS=FOURTH of a sandbox build because the archive version
of the library has not been built yet. It later works on PASS=FIFTH.
But it doesn't resemble how the other shared libraries are derived in
relation to their archive library counterparts.
Please look at those other Makefiles.
There may be Makefile gurus on the "buildhelp" mailing list who can better
advise you on what should be in the makefile. The things I don't like are
the lack of a declared dependence on libtli.a, lack of an "@" on the front
of the echo command, and the copy of the library when it could have been
found and loaded directly through the VPATH.
Thanks,
-- jmcg
|
| 27.3 | RE: shared library makefile conventions | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Tue May 18 1993 16:41 | 91 |
| Date Of Receipt: 14-MAY-1993 16:43:33.62
From: FLUME::krisis::sandeep
To: [email protected], [email protected]
CC: [email protected]
Subj: RE: shared library makefile conventions
I tried to do what you suggested. here is my problem:
The shared library will be built by creating the objects and leaving them
intact. Now when static library is being created, the following rule
triggers the recompilation of the OFILES. I set the VPATH to
include ${MAKETOP}/usr/shlib/libtli where the objects will be found.
${_LIBRARIES_}: ${DEPEND_LIST} ${_LIBRARIES_}($${_LIB_OFILES_})
${_AR_} ${DEF_ARFLAGS} $@ $?
${_RANLIB_} $@
${RM} -f $?
However, i find that recompilation takes place, as if no objects were found
in any of the VPATH directories. This will work fine, but the optimization
(for build time) will not happen. Is there anything I am missing?
Thanks,
sandeep shah
------------------------------------- in reply to
From [email protected] Mon May 10 15:34:20 1993
Date: Mon, 10 May 1993 15:33:49 -0400
From: [email protected] (Kim Peterson, DECwest Engineering)
To: [email protected]
Cc: [email protected], [email protected]
Subject: RE: shared library makefile conventions
You can't use .a libraries to build .so libraries when both are exported
because the shared library export pass occurs before the static library export
pass. You can do it if no other application (or shared library) links with the
shared library, because then the shared library is built in the last pass,
and you would still export the static library (because it was used to link the
shared library).
The reason why the passes are organized this way (and the reason OSF makefiles
compile the same modules twice) is that OSF's compilation system required shared
library modules to be compiled differently from other object modules. This
isn't true of the ALPHA compilation system, and so you might improve the build
time considerably by doing away with the double compilation.
The simplest way for doing this might be to compile the objects directly in the
shared library directoy (see the /usr/shlib/libc/Makefile), and then use those
objects to build the static library by setting VPATH to the shared library
directory). (I'm assuming that the shared library rule does not remove the
objects, but I could be wrong about that). The alternative is to switch the
ordering of the export phases so that static libraries are built before shared
libraries.
--Kim
=========================================================================
From: FLUME::jmcg "Jim McGinness" 10-MAY-1993 11:44:00.22
To: flume::sandeep
CC: flume::buildhelp
Subj: shared library makefile conventions
Sandeep,
The two Makefiles you submitted for usr/shlib/libtli.so and libxti.so show
a failure in sandbox builds, at least in part because of what I think may
be considered an illicit shortcut. Your rule for building the shared libs
looks like:
libtli.so:
echo ${LIBTLISO}
cp -p ${LIBTLISO}/libtli.a .
${_LD_} ${_SHLDFLAGS_} -o [email protected] -all libtli.a ${_LIBS_}
${MV} [email protected] $@
${RM} libtli.a
This fails in PASS=FOURTH of a sandbox build because the archive version
of the library has not been built yet. It later works on PASS=FIFTH.
But it doesn't resemble how the other shared libraries are derived in
relation to their archive library counterparts.
Please look at those other Makefiles.
There may be Makefile gurus on the "buildhelp" mailing list who can better
advise you on what should be in the makefile. The things I don't like are
the lack of a declared dependence on libtli.a, lack of an "@" on the front
of the echo command, and the copy of the library when it could have been
found and loaded directly through the VPATH.
Thanks,
-- jmcg
|
| 27.4 | RE: shared library makefile conventions | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Tue May 18 1993 16:48 | 105 |
| Date Of Receipt: 17-MAY-1993 12:46:09.05
From: KRISIS::decwet::peterson
To: KRISIS::sandeep
CC: KRISIS::"[email protected]"
Subj: RE: shared library makefile conventions
It might be that using the relative file path (using "..") might turn out better
(because I suspect that MAKETOP restricts the search to the source directory
tree, and using the relative path would allow searching in the object directory
tree, because the current working directory during make is in the object
directory tree).
--Kim
=============================================================================
From: KRISIS::sandeep "Sandeep Shah USSG" 14-MAY-1993 13:44:09.74
To: [email protected], [email protected]
CC: [email protected]
Subj: RE: shared library makefile conventions
I tried to do what you suggested. here is my problem:
The shared library will be built by creating the objects and leaving them
intact. Now when static library is being created, the following rule
triggers the recompilation of the OFILES. I set the VPATH to
include ${MAKETOP}/usr/shlib/libtli where the objects will be found.
${_LIBRARIES_}: ${DEPEND_LIST} ${_LIBRARIES_}($${_LIB_OFILES_})
${_AR_} ${DEF_ARFLAGS} $@ $?
${_RANLIB_} $@
${RM} -f $?
However, i find that recompilation takes place, as if no objects were found
in any of the VPATH directories. This will work fine, but the optimization
(for build time) will not happen. Is there anything I am missing?
Thanks,
sandeep shah
------------------------------------- in reply to
From [email protected] Mon May 10 15:34:20 1993
Date: Mon, 10 May 1993 15:33:49 -0400
From: [email protected] (Kim Peterson, DECwest Engineering)
To: [email protected]
Cc: [email protected], [email protected]
Subject: RE: shared library makefile conventions
You can't use .a libraries to build .so libraries when both are exported
because the shared library export pass occurs before the static library export
pass. You can do it if no other application (or shared library) links with the
shared library, because then the shared library is built in the last pass,
and you would still export the static library (because it was used to link the
shared library).
The reason why the passes are organized this way (and the reason OSF makefiles
compile the same modules twice) is that OSF's compilation system required shared
library modules to be compiled differently from other object modules. This
isn't true of the ALPHA compilation system, and so you might improve the build
time considerably by doing away with the double compilation.
The simplest way for doing this might be to compile the objects directly in the
shared library directoy (see the /usr/shlib/libc/Makefile), and then use those
objects to build the static library by setting VPATH to the shared library
directory). (I'm assuming that the shared library rule does not remove the
objects, but I could be wrong about that). The alternative is to switch the
ordering of the export phases so that static libraries are built before shared
libraries.
--Kim
=========================================================================
From: FLUME::jmcg "Jim McGinness" 10-MAY-1993 11:44:00.22
To: flume::sandeep
CC: flume::buildhelp
Subj: shared library makefile conventions
Sandeep,
The two Makefiles you submitted for usr/shlib/libtli.so and libxti.so show
a failure in sandbox builds, at least in part because of what I think may
be considered an illicit shortcut. Your rule for building the shared libs
looks like:
libtli.so:
echo ${LIBTLISO}
cp -p ${LIBTLISO}/libtli.a .
${_LD_} ${_SHLDFLAGS_} -o [email protected] -all libtli.a ${_LIBS_}
${MV} [email protected] $@
${RM} libtli.a
This fails in PASS=FOURTH of a sandbox build because the archive version
of the library has not been built yet. It later works on PASS=FIFTH.
But it doesn't resemble how the other shared libraries are derived in
relation to their archive library counterparts.
Please look at those other Makefiles.
There may be Makefile gurus on the "buildhelp" mailing list who can better
advise you on what should be in the makefile. The things I don't like are
the lack of a declared dependence on libtli.a, lack of an "@" on the front
of the echo command, and the copy of the library when it could have been
found and loaded directly through the VPATH.
Thanks,
-- jmcg
|