You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by tr...@apache.org on 2002/04/19 16:04:30 UTC
cvs commit: httpd-2.0/build instdso.sh
trawick 02/04/19 07:04:30
Modified: . CHANGES
build instdso.sh
Log:
Change instdso.sh to use libtool --install everywhere and then
clean up some stray files and symlinks that libtool leaves around
on some platforms. This gets subversion building properly since
it needed a re-link to be performed by libtool at install time,
and the old instdso.sh logic to simply cp the DSO didn't handle
that requirement.
Submitted by: Sander Striker
Reviewed by: Jeff Trawick
Revision Changes Path
1.716 +7 -0 httpd-2.0/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/httpd-2.0/CHANGES,v
retrieving revision 1.715
retrieving revision 1.716
diff -u -r1.715 -r1.716
--- CHANGES 18 Apr 2002 09:01:31 -0000 1.715
+++ CHANGES 19 Apr 2002 14:04:29 -0000 1.716
@@ -1,5 +1,12 @@
Changes with Apache 2.0.36
+ *) Change instdso.sh to use libtool --install everywhere and then
+ clean up some stray files and symlinks that libtool leaves around
+ on some platforms. This gets subversion building properly since
+ it needed a re-link to be performed by libtool at install time,
+ and the old instdso.sh logic to simply cp the DSO didn't handle
+ that requirement. [Sander Striker]
+
*) Allow VPATH builds to succeed when configured from an empty
directory. [Thom May <th...@planetarytramp.net>]
1.5 +36 -33 httpd-2.0/build/instdso.sh
Index: instdso.sh
===================================================================
RCS file: /home/cvs/httpd-2.0/build/instdso.sh,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- instdso.sh 20 Feb 2002 20:11:32 -0000 1.4
+++ instdso.sh 19 Apr 2002 14:04:30 -0000 1.5
@@ -21,38 +21,41 @@
TARGET_NAME="$DSOBASE.so"
SYS=`uname -s`
-case $SYS in
- AIX)
- # on AIX, shared libraries remain in storage even when
- # all processes using them have exited; standard practice
- # prior to installing a shared library is to rm -f first
- CMD="rm -f $TARGETDIR/$TARGET_NAME"
- echo $CMD
- $CMD || exit $?
- CMD="cp .libs/lib$DSOBASE.so.0 $TARGETDIR/$TARGET_NAME"
- echo $CMD
- $CMD || exit $?
- ;;
- HP-UX)
- CMD="cp .libs/$DSOBASE.sl $TARGETDIR/$TARGET_NAME"
- echo $CMD
- $CMD || exit $?
- ;;
- OSF1)
- CMD="cp .libs/lib$DSOBASE.so $TARGETDIR/$TARGET_NAME"
- echo $CMD
- $CMD || exit $?
- ;;
- OS/2|OS/390)
- CMD="$SH_LIBTOOL --mode=install cp $DSOARCHIVE $TARGETDIR/"
- echo $CMD
- $CMD || exit $?
- ;;
- *)
- CMD="cp .libs/$TARGET_NAME $TARGETDIR/$TARGET_NAME"
- echo $CMD
- $CMD || exit $?
- ;;
-esac
+
+if test "$SYS" = "AIX"
+then
+ # on AIX, shared libraries remain in storage even when
+ # all processes using them have exited; standard practice
+ # prior to installing a shared library is to rm -f first
+ CMD="rm -f $TARGETDIR/$TARGET_NAME"
+ echo $CMD
+ $CMD || exit $?
+fi
+
+CMD="$SH_LIBTOOL --mode=install cp $DSOARCHIVE $TARGETDIR/"
+echo $CMD
+$CMD || exit $?
+
+DLNAME=`grep "^dlname" $TARGETDIR/$DSOARCHIVE | sed -e "s/dlname='\([^']*\)'/\1/"`
+LIBRARY_NAMES=`grep "library_names" $TARGETDIR/$DSOARCHIVE | sed -e "s/dlname='\([^']*\)'/\1/"`
+LIBRARY_NAMES=`echo $LIBRARY_NAMES | sed -e "s/ *$DLNAME//g"`
+
+if test -n "$LIBRARY_NAMES"
+then
+ for f in $LIBRARY_NAMES
+ do
+ rm -f $TARGETDIR/$f
+ done
+fi
+
+if test "$DLNAME" != "$TARGET_NAME"
+then
+ mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
+fi
+
+rm -f $TARGETDIR/$DSOARCHIVE
+rm -f $TARGETDIR/$DSOBASE.a
+rm -f $TARGETDIR/lib$DSOBASE.a
+rm -f $TARGETDIR/lib$TARGET_NAME
exit 0
Re: cvs commit: httpd-2.0/build instdso.sh
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 23 Apr 2002, Greg Ames wrote:
> > Sheesh. Anyone know how to fix that?
>
> you aren't going to like my fixes...
>
> * use static builds for debugging
> * upgrade the OS
I ended up upgrading gdb from 5.0 to 5.1.1 and building it for i686
instead of i386, and between those two changes, it's fixed for DSOs.
Thanks!
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0/build instdso.sh
Posted by Greg Ames <gr...@apache.org>.
Cliff Woolley wrote:
> However, I guess I should have kept my eyes open to what gdb was telling
> me:
>
> warning: Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code.
that sounds familiar
> Sheesh. Anyone know how to fix that?
you aren't going to like my fixes...
* use static builds for debugging
* upgrade the OS
I got the same thing after "upgrading" Linux, maybe to Mandrake 7.2. I googled
and decided it would be a mess to fix by upgrading individual RPMs. I believe
it went away after installing Mandrake 8.0.
Greg
Re: cvs commit: httpd-2.0/build instdso.sh
Posted by Cliff Woolley <jw...@virginia.edu>.
On 19 Apr 2002, Jeff Trawick wrote:
> It should be really easy to test your theory. Just use cp to copy
> your DSO from modules/foo/.libs into the right installed place.
Uggh, that didn't help. :( So I guess I can't blame it on you guys. ;]
However, I guess I should have kept my eyes open to what gdb was telling
me:
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Sheesh. Anyone know how to fix that?
Thanks,
Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0/build instdso.sh
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <jw...@virginia.edu> writes:
> On 19 Apr 2002 trawick@apache.org wrote:
>
> > trawick 02/04/19 07:04:30
> >
> > Modified: . CHANGES
> > build instdso.sh
> > Log:
> > Change instdso.sh to use libtool --install everywhere and then
> > clean up some stray files and symlinks that libtool leaves around
> > on some platforms. This gets subversion building properly since
> > it needed a re-link to be performed by libtool at install time,
> > and the old instdso.sh logic to simply cp the DSO didn't handle
> > that requirement.
>
> I need to experiment with this a bit more, but it looks like it might be
> causing my DSO's to be undebuggable. :( I can't set breakpoints, I can't
> even step into the DSOs -- calls through them get skipped right over.
> Might libtool --install strip away debugging symbols?
It should be really easy to test your theory. Just use cp to copy
your DSO from modules/foo/.libs into the right installed place.
More massive suckage (but let's hope it wasn't instdso.sh or
libtool)...
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: cvs commit: httpd-2.0/build instdso.sh
Posted by Sander Striker <st...@apache.org>.
> From: Cliff Woolley [mailto:jwoolley@virginia.edu]
> Sent: 19 April 2002 20:20
> On 19 Apr 2002 trawick@apache.org wrote:
>
> > trawick 02/04/19 07:04:30
> >
> > Modified: . CHANGES
> > build instdso.sh
> > Log:
> > Change instdso.sh to use libtool --install everywhere and then
> > clean up some stray files and symlinks that libtool leaves around
> > on some platforms. This gets subversion building properly since
> > it needed a re-link to be performed by libtool at install time,
> > and the old instdso.sh logic to simply cp the DSO didn't handle
> > that requirement.
>
> I need to experiment with this a bit more, but it looks like it might be
> causing my DSO's to be undebuggable. :( I can't set breakpoints, I can't
> even step into the DSOs -- calls through them get skipped right over.
> Might libtool --install strip away debugging symbols?
It might, but I surely hope not. And I don't think it does.
How would people debug libtool installed libs otherwise?
> --Cliff
Sander
Re: cvs commit: httpd-2.0/build instdso.sh
Posted by Cliff Woolley <jw...@virginia.edu>.
On 19 Apr 2002 trawick@apache.org wrote:
> trawick 02/04/19 07:04:30
>
> Modified: . CHANGES
> build instdso.sh
> Log:
> Change instdso.sh to use libtool --install everywhere and then
> clean up some stray files and symlinks that libtool leaves around
> on some platforms. This gets subversion building properly since
> it needed a re-link to be performed by libtool at install time,
> and the old instdso.sh logic to simply cp the DSO didn't handle
> that requirement.
I need to experiment with this a bit more, but it looks like it might be
causing my DSO's to be undebuggable. :( I can't set breakpoints, I can't
even step into the DSOs -- calls through them get skipped right over.
Might libtool --install strip away debugging symbols?
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA