Re: instdso.sh - basename confusion
On Tue, 24 Sep 2002 [EMAIL PROTECTED] wrote: > If you already have the .so, why would you use apxs? The whole point of > apxs, is to build the module, and get it into the source tree. If all you > are using apxs for, is to edit the config file, I would suggest that there > are better tools available for that job. Well, that may be another approach. But I *really* like it that apache comes with this 'tool', its own package management if you may say so, which allows you to say; Hey! here is a binary - just suck it in please. So another option would be to have a second 'addmodule' command which understands just enough to do this; i.e. it knows -> where is my server root ? -> is there a mod_so in the httpd binary ? -> where should the modules live ? -> where is the config file and what do I need to add ? -> what file permssions should they have on this platform ? -> do I need to run a postfix command for rebinding ? apxs does 95% of that; perhaps it should do 80% and another util 20%. DW
Re: instdso.sh - basename confusion
On Tue, 24 Sep 2002, Dirk-Willem van Gulik wrote: > > > > And then try to install (on Solaris) a module as a .so: > > > > > > ../a2/bin/apxs -i -n mod_foo mod_foo.so > > > > I would suggest looking at HEAD rather than 2.0.40 as I made changes > > to instdso.sh to explicitly handle this case. instdso.sh will now > > emit a warning rather than error out if you pass it a non-.la > > file. -- justin > > Nice ! Any way of -not- making it need the .la; or being able to do > without it if it is lost ? If you already have the .so, why would you use apxs? The whole point of apxs, is to build the module, and get it into the source tree. If all you are using apxs for, is to edit the config file, I would suggest that there are better tools available for that job. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: instdso.sh - basename confusion
> > And then try to install (on Solaris) a module as a .so: > > > > ../a2/bin/apxs -i -n mod_foo mod_foo.so > > I would suggest looking at HEAD rather than 2.0.40 as I made changes > to instdso.sh to explicitly handle this case. instdso.sh will now > emit a warning rather than error out if you pass it a non-.la > file. -- justin Nice ! Any way of -not- making it need the .la; or being able to do without it if it is lost ? Dw
Re: instdso.sh - basename confusion
On Tue, Sep 24, 2002 at 01:47:52PM +0200, Dirk-Willem van Gulik wrote: > Hmm - I do a normal install > > cd apache-2.0.40 > ./configure --prefix=../a2 > make && make install > > And then try to install (on Solaris) a module as a .so: > > ../a2/bin/apxs -i -n mod_foo mod_foo.so I would suggest looking at HEAD rather than 2.0.40 as I made changes to instdso.sh to explicitly handle this case. instdso.sh will now emit a warning rather than error out if you pass it a non-.la file. -- justin
Re: instdso.sh - basename confusion
On 24 Sep 2002, Jeff Trawick wrote: > > Ok - I get it - so that means that a sysadmin would need to keep/move both > > files around as he or she installs some extra binary modules on a > > machine. > > or tar up the .la file and the .libs subdirectory? Well - just fishing the .so file out of .libs and filing it together with the .la file should be enough right ? > or install it once and keep the resulting .so file? Well - but in order to reproduce it a year hence - we'd need to keep both an .la and a .so. > > Is there not a way this could be reduced to just one file - perhaps even > > comping the .la information inside the mod_foo.so; and then have some > > query utility which at run time link in the SO and then extracts this > > info. All we seem to use is the dlname string ? > > or modify apxs to reverse-engineer the libtool mysteries at compile > time instead of link time, so that the compile results in .so and > nothing else Hmm - but then we'd not really be using libtool anymore. I.e. we're redcing it almost to a 'knowledge base' which just knows which '-shared -fpic' flags to specify to cc/ld on various platforms. Even 'odd' ones like MacOS X and NeXt are not that different. But then again - it would be very nice to just shunt things around as a signle file; give it to apxs and be done with it. (And for now we propably need to tell axps to give us a decent error if you try to let it operate on a .la file without the .so or vice versa). Dw
Re: instdso.sh - basename confusion
Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > > unless something has changed very recently, apxs with Apache 2.0 is > > intended to be passed the name of the .la file, not the .so file > > > > in general, the module author will know where the .la file was built > > by apxs -c but will not know the exact name of the .so file (which > > could be .libs/mod_foo.so or .libs/libmod_foo.so or > > .libs/libmod_foo.sl or who knows what else) > > Ok - I get it - so that means that a sysadmin would need to keep/move both > files around as he or she installs some extra binary modules on a > machine. or tar up the .la file and the .libs subdirectory? or install it once and keep the resulting .so file? > Is there not a way this could be reduced to just one file - perhaps even > comping the .la information inside the mod_foo.so; and then have some > query utility which at run time link in the SO and then extracts this > info. All we seem to use is the dlname string ? or modify apxs to reverse-engineer the libtool mysteries at compile time instead of link time, so that the compile results in .so and nothing else -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: instdso.sh - basename confusion
On 24 Sep 2002, Jeff Trawick wrote: > Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > > > On Tue, 24 Sep 2002, Sander Striker wrote: > > > > > Nope. It is intented to remove any leading directory components. > > > > Hmm - I do a normal install > > > > cd apache-2.0.40 > > ./configure --prefix=../a2 > > make && make install > > > > And then try to install (on Solaris) a module as a .so: > > > > ../a2/bin/apxs -i -n mod_foo mod_foo.so > > unless something has changed very recently, apxs with Apache 2.0 is > intended to be passed the name of the .la file, not the .so file > > in general, the module author will know where the .la file was built > by apxs -c but will not know the exact name of the .so file (which > could be .libs/mod_foo.so or .libs/libmod_foo.so or > .libs/libmod_foo.sl or who knows what else) Ok - I get it - so that means that a sysadmin would need to keep/move both files around as he or she installs some extra binary modules on a machine. Is there not a way this could be reduced to just one file - perhaps even comping the .la information inside the mod_foo.so; and then have some query utility which at run time link in the SO and then extracts this info. All we seem to use is the dlname string ? Dw
Re: instdso.sh - basename confusion
Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > On Tue, 24 Sep 2002, Sander Striker wrote: > > > Nope. It is intented to remove any leading directory components. > > Hmm - I do a normal install > > cd apache-2.0.40 > ./configure --prefix=../a2 > make && make install > > And then try to install (on Solaris) a module as a .so: > > ../a2/bin/apxs -i -n mod_foo mod_foo.so unless something has changed very recently, apxs with Apache 2.0 is intended to be passed the name of the .la file, not the .so file in general, the module author will know where the .la file was built by apxs -c but will not know the exact name of the .so file (which could be .libs/mod_foo.so or .libs/libmod_foo.so or .libs/libmod_foo.sl or who knows what else) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: instdso.sh - basename confusion
On Tue, 24 Sep 2002, Dirk-Willem van Gulik wrote: > mv: /disk/raid0/home/dirkx/tmp/a2/modules is a directory > chmod 755 /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so > chmod: WARNING: can't access /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so > apxs:Error: Command failed with rc=65536 > . Ok, so it is right at the end --> rm -f $TARGETDIR/$DSOARCHIVE_BASENAME rm -f $TARGETDIR/$DSOBASE.a rm -f $TARGETDIR/lib$DSOBASE.a rm -f $TARGETDIR/lib$TARGET_NAME exit 0 that top line wacks the just installed archive. The name comes from DSOARCHIVE=$2 DSOARCHIVE_BASENAME=`basename $2` and is the 'dso-name' passed. What is the idea behind this delete ? Dw
RE: instdso.sh - basename confusion
On Tue, 24 Sep 2002, Sander Striker wrote: > Nope. It is intented to remove any leading directory components. Hmm - I do a normal install cd apache-2.0.40 ./configure --prefix=../a2 make && make install And then try to install (on Solaris) a module as a .so: ../a2/bin/apxs -i -n mod_foo mod_foo.so This fails: mv: /disk/raid0/home/dirkx/tmp/a2/modules is a directory chmod 755 /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so chmod: WARNING: can't access /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so apxs:Error: Command failed with rc=65536 . Which is I think in instdso.sh. See the -x trace below. Dw. dirkx@nagoya:/disk/raid0/home/dirkx/tmp/ttkg2 $ ../a2/bin/apxs -i -n mod_foo mod_foo.so/disk/raid0/home/dirkx/tmp/a2/build/instdso.sh SH_LIB TOOL='/disk/raid0/home/dirkx/tmp/a2/build/libtool' mod_foo.so /disk/raid0/home/dirkx/tmp/a2/modules + test 3 != 3 + sed -e s/^SH_LIBTOOL=// + echo SH_LIBTOOL=/disk/raid0/home/dirkx/tmp/a2/build/libtool SH_LIBTOOL=/disk/raid0/home/dirkx/tmp/a2/build/libtool DSOARCHIVE=mod_foo.so + basename mod_foo.so DSOARCHIVE_BASENAME=mod_foo.so TARGETDIR=/disk/raid0/home/dirkx/tmp/a2/modules + sed + echo-e mod_foo.so s/\.la$// -e s/\.so$// DSOBASE=mod_foo TARGET_NAME=mod_foo.so + uname -s SYS=SunOS + test SunOS = AIX CMD=/disk/raid0/home/dirkx/tmp/a2/build/libtool --mode=install cp mod_foo.so /disk/raid0/home/dirkx/tmp/a2/modules/ + echo /disk/raid0/home/dirkx/tmp/a2/build/libtool --mode=install cp mod_foo.so /disk/raid0/home/dirkx/tmp/a2/modules/ /disk/raid0/home/dirkx/tmp/a2/build/libtool --mode=install cp mod_foo.so /disk/raid0/home/dirkx/tmp/a2/modules/ + /disk/raid0/home/dirkx/tmp/a2/build/libtool --mode=install cp mod_foo.so /disk/raid0/home/dirkx/tmp/a2/modules/ cp mod_foo.so /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so + test SunOS = OS/2 + sed -e s/dlname='\([^']*\)'/\1/ + grep ^dlname /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so DLNAME= + sed -e s/dlname='\([^']*\)'/\1/ + grep library_names /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so LIBRARY_NAMES= + sed -e s/ *//g + echo LIBRARY_NAMES= + test -n + test != mod_foo.so + mv /disk/raid0/home/dirkx/tmp/a2/modules/ /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so mv: /disk/raid0/home/dirkx/tmp/a2/modules is a directory + rm -f /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so + rm -f /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.a + rm -f /disk/raid0/home/dirkx/tmp/a2/modules/libmod_foo.a + rm -f /disk/raid0/home/dirkx/tmp/a2/modules/libmod_foo.so + exit 0 chmod 755 /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so chmod: WARNING: can't access /disk/raid0/home/dirkx/tmp/a2/modules/mod_foo.so apxs:Error: Command failed with rc=65536 . Dw
RE: instdso.sh - basename confusion
> From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]] > Sent: 24 September 2002 13:32 > One for the libtool experts: > > In instdso.sh we do a 'basename $2' - which I assume is intended to strip > of any .so ?? Nope. It is intented to remove any leading directory components. Sander
instdso.sh - basename confusion
One for the libtool experts: In instdso.sh we do a 'basename $2' - which I assume is intended to strip of any .so ?? DSOARCHIVE=$2 DSOARCHIVE_BASENAME=`basename $2` But should that not be: DSOARCHIVE_BASENAME=`basename $2 .so` Or are there platforms where basename strips extensions -without- specifiying them ? Then we continue to strip it further for .la's: DSOBASE=`echo $DSOARCHIVE_BASENAME | sed -e 's/\.la$//'` TARGET_NAME="$DSOBASE.so" So it kind of seems double. The problem is right now for me that I get complains from either not finding a mod_foo.so.so or it reducing it to a move of just mod_foo. Thinks work (on Solaris) when I add the .so to the above basename. But I do not want to commit this fix as I do not understand the implications. Dw
