We give you $200 bonus at Casino Zeal!

[Rich Hudson]

Hi, 
I have a special offer available for you at our casino.

$200 bonus on your first deposit!
At the casino software's cashier enter bonus code: FMJKU

Allow us to show you our quality operation, fast payouts,
generous bonuses, and super friendly around-the-clock
customer support.

Click here: http://bigbonus-casino.net 

Best regards,
Jamie Zawinsky



No thanks: http://bigbonus-casino.net/u/



___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

ltmain.sh

[Gary V. Vaughan]

Hi Alexandre!

Having automake choke when ltmain.sh is missing causes no end
of trouble for libtool... because obviously we don't have ltmain.sh
yet at bootstrap time.  We work around it by having a bootstrap
script touch ltmain.sh before running automake, and then removing
it so that make triggers the right rules to rebuild it properly.

None of the automatic rebuild rules work:

] make
cd .. && /bin/sh /Users/gary/devel/savannah/libtool--devo--1.0/config/missing
--run automake-1.8c --gnits  Makefile
configure.ac:179: required file `config/ltmain.sh' not found
make: *** [../Makefile.in] Error 1

And worst of none of the dist rules work properly.  In a VPATH build
tree, we make ./config/ltmain.sh, but automake expects to see it in
$(srcdir)/config/ltmain.sh and chokes:

] make dist
{ test ! -d libtool-1.5a || { find libtool-1.5a -type d ! -perm -200 -exec
chmod u+w {} ';' && rm -fr libtool-1.5a; }; }
mkdir libtool-1.5a
mkdir -p -- . libtool-1.5a/. libtool-1.5a/config libtool-1.5a/m4
...
make[2]: *** No rule to make target
`/Users/gary/devel/savannah/libtool--devo--1.0/tests/cdemo/../../config/ltmain.sh',
needed by `distdir'.  Stop.
make[1]: *** [distdir] Error 1
make: *** [distdir] Error 1

If I copy everything into a new tree and configure in top_srcdir, make
dist will work, but distcheck fails the VPATH tests :-(

I've added the following rules to the top-level Makefile.am, and they
do mitigate things a lot:

$(top_srcdir)/config/ltmain.sh: config/ltmain.sh
$(LN_S) config/ltmain.sh $(top_srcdir)/config/ltmain.sh

dist-hook:
test -f $(top_distdir)/config/ltmain.sh || \
  $(LN_S) config/ltmain.sh $(top_distdir)/config/ltmain.sh

I think that what we *really* need is for automake to not assume ltmain.sh
is in the source tree, and some way for the libtool Makefile.am to
declare that config/ltmain.sh is a built file so that automake doesn't
keep stopping before it is built without the horrible bootstrap $fakes
hack.

Unfortunately, at the moment we need to rebootstrap the whole tree far
more often than necessary where other projects just rerun automake as
part of the make invocation.  Rerunning autoreconf -fvi on all 8 test/*demo*
trees and the libtool source tree proper after every cvs update and commit
takes about 30 minutes on my high end Mac, and up to an hour for some of
our other developers :-(

Thoughts?

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: cvs build prob

[Patrick Welche]

On Wed, Jul 28, 2004 at 06:38:56PM +0100, Gary V. Vaughan wrote:
> If you revert my patch, or fetch the prepatch revision from my arch
> mirror, and bootstrap with HEAD autoconf, does the new AS_SHELL_SANITIZE
> from autoconf prevent the crash when setting output_verbose_link_cmd?

That's it - I first just tried installing a new cvs-autoconf with Paul's
patch. That didn't fix the LT_LANG(C++) using quoting problem. I then
got rid of the backslashes as per your patch, and that made libtool.m4
happy.

Cheers,

Patrick


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool $libs question

[Chris Burdess]

Peter O'Gorman wrote:
I need a bit of help fixing the JNI build for gnujaxp, perhaps 
someone familiar with libtool could comment:
All goes well until the link step. Then, under Darwin, I'm issuing 
the following:
/bin/sh ./libtool --mode=link gcc -shared -rpath /usr/local/lib
-release 0.99 -export-dynamic -D_JNI_IMPLEMENTATION_ -L/usr/local/lib 
-lxslt -lxml2 -lz -lpthread -liconv -lm -shrext .jnilib -o libxmlj.la 
 xmlj_dom.lo  xmlj_error.lo  xmlj_io.lo  xmlj_node.lo  xmlj_sax.lo  
xmlj_transform.lo  xmlj_util.lo  xmlj_xpath.lo
libtool converts this to
gcc -dynamiclib  -flat_namespace -undefined suppress -o 
.libs/libxmlj-0.99.jnilib  .libs/xmlj_dom.o .libs/xmlj_error.o 
.libs/xmlj_io.o .libs/xmlj_node.o .libs/xmlj_sax.o 
.libs/xmlj_transform.o .libs/xmlj_util.o .libs/xmlj_xpath.o  
-L/usr/local/lib /usr/local/lib/libxslt.dylib /usr/lib/libm.dylib 
/usr/local/lib/libxml2.dylib /usr/lib/libpthread.dylib 
/usr/lib/libz.dylib -lz -lpthread /usr/lib/libiconv.dylib -lm 
-install_name  /usr/local/lib/libxmlj-0.99.jnilib
Problem is, this is wrong, and results in an unlinkable shared 
object. How do I get libtool to leave the -l arguments alone?
What's wrong with it exactly? This is on a Mac OS X/darwin system, 
right?

Since it looks like you are building a loadable java extension, you 
might like to try the -module flag. -export-dynamic is meant (as far 
as I know) for building executables, it allows the executables global 
symbols to be made available to modules.
Thanks for the reply. Under Darwin, -module ends up as -bundle, which 
is not appropriate for a JNI library (?) but you're right, I don't need 
-export-dynamic.

I've tracked down the problem - it's not the rewriting of $libs that 
causes it, it's compiling against an incompatible version of jni.h.

Thanks anyway
--
Chris Burdess

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: cvs build prob

[Patrick Welche]

On Wed, Jul 28, 2004 at 11:22:09AM -0700, Paul Eggert wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> 
> > -elif test -n "${BASH_VERSION+set}${KSH_VERSION+set}" && (set -o posix) >/dev/null 
> > 2>&1; then
> > +elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then
> >set -o posix
> > +elif test -n "${KSH_VERSION+set}" && (set +o posix) >/dev/null 2>&1; then
> > +  set +o posix
> 
> You need "set +o posix" for pdksh?  Doesn't that disable POSIX compatibility?

yes ?!

> Hmm, why would this fix things?  Autoconf uses what is supposed to be
> a subset of plain POSIX; we don't want to encourage shells to be
> incompatible with POSIX.

Well, here is

== bar ===
set -o posix
Xsed='sed -e s/^X//'
no_glob_subst='s/\*/\\\*/g'

output_cmd="hello"
echo "output_cmd: ($output_cmd)"
output_one="`echo \"X$output_cmd\" | $Xsed -e \"$no_glob_subst\"`"
echo "output_one: ($output_cmd)"
output_two=`echo "X$output_cmd" | $Xsed -e "$no_glob_subst"`
echo "output_two: ($output_cmd)"
output_tri=$(echo "X$output_cmd" | $Xsed -e "$no_glob_subst")
echo "output_tri: ($output_cmd)"
===
% ksh bar
output_cmd: (hello)
sed: 1: ""s/\*/\\\*/g"": invalid command code "
output_one: (hello)
output_two: (hello)
output_tri: (hello)

However, if I change that first line to set +o posix,

% ksh bar
output_cmd: (hello)
output_one: (hello)
output_two: (hello)
output_tri: (hello)

@(#)PD KSH v5.2.14 99/07/13.2

which is the same output as with sh, and no seting of posix.

Quoting from ksh(1):

   Note:  see  POSIX  Mode below for a special rule regarding sequences of
   the form "...`...\"...`..".
...
   POSIX Mode
   The shell is intended to be POSIX compliant, however,  in  some  cases,
   POSIX behaviour is contrary either to the original Korn shell behaviour
   or to user convenience.  How the shell behaves in these cases is deter-
   mined  by  the state of the posix option (set -o posix) -- if it is on,
   the POSIX behaviour is followed, otherwise it is not.  The posix option
   is  set  automatically when the shell starts up if the environment con-
   tains the POSIXLY_CORRECT parameter.  (The shell can also  be  compiled
   so  that  it  is  in POSIX mode by default, however this is usually not
   desirable).

   The following is a list of things that are affected by the state of the
   posix option:
 o\"  inside  double  quoted  `..` command substitutions: in posix
  mode, the \" is interpreted when the command is interpreted;  in
  non-posix  mode,  the  backslash  is stripped before the command
  substitution is interpreted.  For example, echo "`echo  \"hi\"`"
  produces `"hi"' in posix mode, `hi' in non-posix mode.  To avoid
  problems, use the $(...)  form of command substitution.


Cheers,

Patrick


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: cvs build prob

[Gary V. Vaughan]

Patrick Welche wrote:
> On Wed, Jul 28, 2004 at 06:38:56PM +0100, Gary V. Vaughan wrote:
> 
>>If you revert my patch, or fetch the prepatch revision from my arch
>>mirror, and bootstrap with HEAD autoconf, does the new AS_SHELL_SANITIZE
>>from autoconf prevent the crash when setting output_verbose_link_cmd?
> 
> 
> That's it - I first just tried installing a new cvs-autoconf with Paul's
> patch. That didn't fix the LT_LANG(C++) using quoting problem. I then
> got rid of the backslashes as per your patch, and that made libtool.m4
> happy.

That's bad :-(

I've only been able to remove the bogus nested escaped double quotes in
some of libtool.m4, including the one that triggers with your particular
combination of host, compiler and shell.  If the AS_SHELL_SANITIZE isn't
placating pdksh, then other combinations of host/compiler/shell will
still trip over the quotes I couldn't strip.

The key is in this part of the manual page:

  echo "`echo \"hi\"`" produces `"hi"' in posix mode, `hi' in non-posix mode

Let's see what bash does:

bash$ echo "`echo \"hi\"`"
hi
bash$ set -o posix
bash$ echo "`echo \"hi\"`"
hi

And now pdksh:

ksh$ echo "`echo \"hi\"`"
hi
ksh$ set -o posix
ksh$ echo "`echo \"hi\"`"
"hi"
ksh$ set +o posix
ksh$ echo "`echo \"hi\"`"
hi

So, it appears that pdksh is confused over what the posix behaviour should
be :-(

I think autoconf should test for that bug and skip a shell that has it when
searching for a suitable shell...

Paul?

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: ltmain.sh

[Alexandre Duret-Lutz]

>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:

[...]

 Gary> I think that what we *really* need is for automake to not
 Gary> assume ltmain.sh is in the source tree, and some way for
 Gary> the libtool Makefile.am to declare that config/ltmain.sh
 Gary> is a built file so that automake doesn't keep stopping
 Gary> before it is built without the horrible bootstrap $fakes
 Gary> hack.

Two answers: short-term, and long-term.

short-term:

  IMHO you are swimming against the stream, that's why it looks
  hard.  Consider the following:

  Automake wants to distribute that file?  So let's distribute
  it.  The file is distributed?  So let's update it in the
  source tree.  The file is expected to be identical for all
  users installing the same revision of libtool?  So let's not
  build it from ./configure (you should not do this for a
  distributed file anyway): have it created by bootstrap and
  write a custom Makefile rule that updates the file whenever
  configure.ac changes.

  This way you meet Automake expectations and never have to lie
  to it, so things should work as expected.  The drawback is
  that you'll waste a few kilobytes, but I don't think the
  economy is worth the irritation one gets debugging clumsy
  hacks.

  Automake has a similar issue with its m4/amversion.m4 file.
  It must be generated from m4/amversion.in, but it's also a
  prerequisite to run autoconf.  The setup is similar to the one
  I suggest above (except the rebuild rule does not depend on
  configure.ac because a bootstrap is needed anyway).

long-term:

  To reduce the amount of hard-coded knowledge in Automake, I'd
  like to introduce a macro, say AM_REQUIRE_AUX_FILE, so that
  third-party Autoconf macros can instruct automake to
 1. check that the files they need are present,
 2. distribute them.

  Libtool could be equipped with
m4_ifdef([A][M_REQUIRE_AUX_FILE], [A][M_REQUIRE_AUX_FILE([ltmain.sh])])
  and the hard coded test removed from Automake.

  Then it seems it would not be too difficult to disable the
  above line in libtool itself, so that Automake never bothers
  about ltmain.sh.

[...]

 Gary> Rerunning autoreconf -fvi on all 8 test/*demo* trees and
 Gary> the libtool source tree proper after every cvs update and
 Gary> commit takes about 30 minutes on my high end Mac, and up
 Gary> to an hour for some of our other developers :-(

Does it?  Running ./bootstrap takes 8 minutes on my poor PC.
--
Alexandre Duret-Lutz



___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

cheap pharmacy prices

[Sobek]

Title: Untitled Document






  

  
SAVE 70% 
SHIPPED WORLDWIDE 
  


  Valium
  Viagra
  Cialis


  
30 pill bottle
+ 5 FREE PILLS
  

  
35 pill bottle
+ 5 FREE PILLS
  
  20 pill bottle
  + 5 FREE PILLS


  
$ 90.00
save $ 50!!
  
  
$ 87.50
save $ 73!!
  
  
$ 140.00
save $ 75!!
  


  Soma
  Xanax
  Levitra


  50 pill bottle
  + 5 FREE PILLS
  30 pill bottle
  + 5 FREE PILLS
  30 pill bottle
  + 5 FREE PILLS


  

  $ 100.00
  save $ 175!!

  
  
  
$ 66.00
save $ 74!!
  
  $ 180.00
  save $ 48!!

  
   
   
   
   
  no more
   
   
  Ron  Industries Limited
D4, 24, Borrett Road, Mid-Levels West
Hong Kong
    







___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: cvs build prob

[Paul Eggert]

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:

> it appears that pdksh is confused over what the posix behaviour should
> be :-(

Yup.  That part of the POSIX spec is confusing, but if you look in 2.2.2

it says

  The portion of the quoted string from the initial backquote and the
  characters up to the next backquote that is not preceded by a
  backslash, having escape characters removed, defines that command
  whose output replaces "`...`"

Here "escape characters" means

   backslashes followed by $, `, ", \, or newline

and hence "`echo \"hi\"`" is evaluated by running the command

  echo "hi"

not

  echo \"hi\"

So pdksh is incorrect here when it is running in POSIX mode.

Pdksh seems to be relatively unmaintained now.  Can whoever is using
it in this thread (sorry, I've lost track) please file a bug report
with whoever's in charge of his copy?  It's clearly broken.


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: cvs build prob

[Paul Eggert]

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:

> I think autoconf should test for that bug and skip a shell that has it when
> searching for a suitable shell...

The Autoconf manual states that portable shell scripts should never
use "`...\"...\"...`" constructs due to severe portability constructs,
so it doesn't seem wise for Autoconf to test for that bug (it sounds
like it would eliminate too many shells :-).

I installed the following doc patch to warn about this, though.  This
patch also cleans up some naming/quoting glitches, so you'll have to
scan for "pdksh" to see the meat.

2004-07-29  Paul Eggert  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Shellology): Mention BIN_SH.
Document problem with "`""`" in pdksh POSIX mode.

Index: autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.824
retrieving revision 1.825
diff -p -u -r1.824 -r1.825
--- autoconf.texi   29 Jul 2004 22:29:16 -  1.824
+++ autoconf.texi   30 Jul 2004 00:34:27 -  1.825
@@ -9332,7 +9332,7 @@ Below we describe some of the members of
 @table @asis
 @item Ash
 @cindex Ash
[EMAIL PROTECTED] is often used on @acronym{GNU}/Linux and @acronym{BSD}
+Ash is often used on @acronym{GNU}/Linux and @acronym{BSD}
 systems as a light-weight Bourne-compatible shell.  Ash 0.2 has some
 bugs that are fixed in the 0.3.x series, but portable shell scripts
 should work around them, since version 0.2 is still shipped with many
@@ -9366,7 +9366,7 @@ Substitutions}, item ``Command Substitut
 
 @item Bash
 @cindex Bash
-To detect whether you are running @command{bash}, test whether
+To detect whether you are running Bash, test whether
 @code{BASH_VERSION} is set.  To require
 @acronym{POSIX} compatibility, run @samp{set -o posix}.  @xref{Bash POSIX
 Mode,, Bash @acronym{POSIX} Mode, bash, The @acronym{GNU} Bash Reference
@@ -9374,12 +9374,12 @@ Manual}, for details.
 
 @item Bash 2.05 and later
 @cindex Bash 2.05 and later
-Versions 2.05 and later of @command{bash} use a different format for the
+Versions 2.05 and later of Bash use a different format for the
 output of the @command{set} builtin, designed to make evaluating its
 output easier.  However, this output is not compatible with earlier
-versions of @command{bash} (or with many other shells, probably).  So if
-you use @command{bash} 2.05 or higher to execute @command{configure},
-you'll need to use @command{bash} 2.05 for all other build tasks as well.
+versions of Bash (or with many other shells, probably).  So if
+you use Bash 2.05 or higher to execute @command{configure},
+you'll need to use Bash 2.05 for all other build tasks as well.
 
 @item Ksh
 @cindex Ksh
@@ -9395,15 +9395,6 @@ on some hosts if you set your path appro
 
 @itemize @minus
 @item
[EMAIL PROTECTED] @samp{pdksh}
-A public-domain clone of the Korn shell called @samp{pdksh} is
-widely available: it has most of the @samp{ksh88} features along with
-a few of its own.
-Similarly to @command{bash}, you can detect whether you are running
[EMAIL PROTECTED] by testing whether @code{KSH_VERSION} is set, and you can
-require @acronym{POSIX} compatibility by running @samp{set -o posix}.
-
[EMAIL PROTECTED]
 Solaris systems have three variants:
 @prindex @command{/usr/bin/ksh} on Solaris
 @command{/usr/bin/ksh} is @samp{ksh88},
@@ -9425,6 +9416,30 @@ the standard shell conform to @acronym{P
 
 @end itemize
 
[EMAIL PROTECTED] Pdksh
[EMAIL PROTECTED] @samp{pdksh}
+A public-domain clone of the Korn shell called @command{pdksh} is widely
+available: it has most of the @samp{ksh88} features along with a few of
+its own.  Similarly to Bash, you can detect whether you are
+running @command{pdksh} by testing whether @code{KSH_VERSION} is set,
+and you can require @acronym{POSIX} compatibility by running @samp{set
+-o posix}.  Unfortunately, with @command{pdksh} 5.2.14 (the latest
+stable version as of July 2004) @acronym{POSIX} mode is buggy and causes
[EMAIL PROTECTED] to depart from @acronym{POSIX} in at least one respect:
+
[EMAIL PROTECTED]
+$ echo "`echo \"hello\"`"
+hello
+$ set -o posix
+$ echo "`echo \"hello\"`"
+"hello"
[EMAIL PROTECTED] example
+
+The last line of output contains spurious quotes.  This is yet another
+reason why portable shell code should not contain
[EMAIL PROTECTED]"[EMAIL PROTECTED]"@dots{}\"@dots{}`"} constructs (@pxref{Shell
+Substitutions}).
+
 @item Zsh
 @cindex Zsh
 To detect whether you are running @command{zsh}, test if
@@ -9502,7 +9517,7 @@ bash-2.04$ @kbd{cat