Re: License of m4/ltoptions.m4

2004-11-11 Thread Gary V. Vaughan
Now for the note to the FSF that explains why we need it... here
is a first cut to get the ball rolling:
Autoconf, Automake and Libtool have long distributed m4 macro
files that are needed to generate the familiar configure script.
In the spirit of giving our users all the same rights that we
developers have, our intention has always been to allow our
users to distribute these m4 macros with their packages so that
*their* users can regenerate the configure script if, say, they
want to make a patch to get things to work on a platform that
the package maintainer didn't have access to.
For this purpose, all 3 autotools have historically had an
exception to the GPL in those source files containing m4 macros
used to generate a package configuration script, but unfortunately
we have used different wordings and in a few cases forgotten to
add the exception clause to a macro source file.
We would jointly like to standardise on the wording of the
exception clause, and add it into the few files that are
currently missing it.
As the copyright holder of these tools, our questions to you are:
  i) Is it okay for us to change the wording of the licenses in
 our m4 macro source files, and in some cases add in the
 missing exception clause, to clarify the spirit in which
 they have been distributed all along?
 ii) Is the following wording sufficiently clear from a legal
 point of view?
Alexandre Duret-Lutz wrote:
Paul == Paul Eggert [EMAIL PROTECTED] writes:

[...]
 Paul As a special exception to the GNU General Public License,
 Paul if you distribute this file as part of a package that
 Paul automatically derives from this file a configuration
 Paul script (and perhaps some associated intermediate files),
 Paul then you may distribute this file and the derived files
 Paul for that purpose, under the same terms that you use for
 Paul the rest of the package.
[...]
President Eggert, you have my vote!
Seconded :-)
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


未承諾広告※5000円で開業してみませんか

2004-11-11 Thread hayabusa

$BHNGd5Bz9-9p"((B $B$4LBOG$JJ}$O:o=|$7$F$/[EMAIL PROTECTED](B
$BEv9-9p$rh$jCY$l$F$b#2HVEEh$jCY$l$k$J!*(B!
$B3+6H%Q%C%/EEh$jCY$l$J$$$G$/(B
(B[EMAIL PROTECTED](B
$B>pJs2=$N;~Be(B,$B>[EMAIL PROTECTED](%M%k%.!<(B
$B$G$9!#I4J9$O0l8+$KG!$+$:$G$9!#0lEY8+$F$/[EMAIL PROTECTED](B
(B
(B   http://koike.mydns.jp/
(B
(B
(B___
(BLibtool mailing list
([EMAIL PROTECTED]
(Bhttp://lists.gnu.org/mailman/listinfo/libtool

Re: TODO

2004-11-11 Thread Scott James Remnant
On Wed, 2004-11-10 at 12:17 -0600, Bob Friesenhahn wrote:

 On Wed, 10 Nov 2004, Ralf Wildenhues wrote:
 
  However it *also* provides the right -I flags to point at the include
  files.  A GTK+ application will '#include gtk/gtkbutton.h' for example
  and require -I/usr/include/gtk-2.0 to actually be able to find that (or
  -1.0, -3.0, etc.)
 
  That's a good feature.  Dunno whether I want that (or it can even be) in
  a .la file or not.  But letting libtool output both information might
  prove valuable.  Absorbing pkgconfig in libtool in a way that each
  pkgconfig user must use libtool will pave way for quote some resistance,
  I'd expect.
 
 pkg-config does not issue the right -I flags.  It merely proposes 
 some based on where the package is installed.  This is fine if the 
 package is used in isolation.  Sometimes these flags work ok in 
 conjuction with flags from other unrelated packages, but other times 
 it results in a bloody mess and wrong behavior.
 
It should never do ... the intent is that the directory specified by the
-I flag *only* contains the include files of the given package;
otherwise you'd be doing -I/usr/include or similar which pkg-config
specifically removes from any output.

Do you have an example of the wrong behaviour?

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Re: License of m4/ltoptions.m4

2004-11-11 Thread Scott James Remnant
On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote:

 As a special exception to the GNU General Public License, if you
 distribute this file as part of a package that automatically derives
 from this file a configuration script (and perhaps some associated
 intermediate files), then you may distribute this file and the derived
 files for that purpose, under the same terms that you use for the rest
 of the package.
 
Has my vote.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Re: License of m4/ltoptions.m4

2004-11-11 Thread Bruce Korb
Scott James Remnant wrote:
 
 On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote:
 
  As a special exception to the GNU General Public License, if you
  distribute this file as part of a package that automatically derives
  from this file a configuration script (and perhaps some associated
  intermediate files), then you may distribute this file and the derived
  files for that purpose, under the same terms that you use for the rest
  of the package.
 
 Has my vote.

My public domain comment notwithstanding, anything approximately close
to the desired verbiage is close enough.  I'd guess that no matter what
you start with, it will change after lawyers have their say.  Therefore,
this is a reasonable enough approximation.  :)


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


Re: License of m4/ltoptions.m4

2004-11-11 Thread Paul Eggert
Gary V. Vaughan [EMAIL PROTECTED] writes:

 Now for the note to the FSF that explains why we need it... here
 is a first cut to get the ball rolling:

That looks fine to me.  Thanks.


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


Re: TODO

2004-11-11 Thread Noah Misch
On Wed, Nov 10, 2004 at 10:44:33PM +0100, Alexandre Duret-Lutz wrote:
 Strictly speaking automake does not know these dependencies.  It
 knows some dependencies, but because of the possibility to
 AC_SUBST variables for conditional linking, and doest not know
 exactly all of them (think libfoo_la_DEPENDENCIES = @SOME_LA@).
 However these dependencies are indeed known later at make time.

I had forgotten.  Bother.

  Noah If Automake generated an install target for installable
  Noah product, just as it generated a build target, would that
  Noah not solve this problem?  
 
 This sounds appealing, but wouldn't this imply that if two
 libraries depends on another one, the later will be installed
 twice?

Time stamp files would prevent that, but I don't know offhand how to handle
@FOO@ cleanly.  I'll play with a few ideas.  Thanks for the feedback.


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


Re: TODO

2004-11-11 Thread Albert Chin
On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
 On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
 
  6.  Absorb the functionality of the aberration called pkg-config.  Libtool
  already has all the information it needs, we just need to teach it (or
  maybe a subsidiary script) to spit out link flags after poking around
  in a dependency chain of .la files.

 There's actually a couple of things pkg-config does that Libtool doesn't
 currently do.  pkg-config's main job can be summed up simply as enabling
 parallel-installed -dev packages.

What about non-libtool libraries wanting to benefit from pkg-config?
This will require them to spit out .la files rather than .pc files.

 Principally it provides the right -L and -l flags to link libraries, we
 can get this from Libtool.  An an improvement would then be only
 providing the dependency -l flags on platforms that need it, and not on
 Linux for example.

Ick. Libtool is about portably building/using libraries. Why can't we
leave it at that?

-- 
albert chin ([EMAIL PROTECTED])


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


libtool 1.5.6 still not supporting make distcheck

2004-11-11 Thread Sean Dague
The issue I reported a couple weeks ago is still there.  We have now tracked
down based on a number of versions of libtool to figure out what works and
what doesn't.

libtool 1.4.x - all versions work that we've tried
libtool 1.5.2 - works
libtool 1.5.6 - doesn't work
libtool 1.5.10 - doesn't work

The end of the logs are included at the end of this email (on libtool 1.5.6):

What is most interesting is that the
/home/sdague/tmp/am-dc-21838//home/sdague/openhpi/openhpi-1.9.3/ directory
doesn't exist at all on my system.  That seems to be created very late in
the make distcheck processing, but why it isn't there I'm not sure.

If anyone would like to run this themselves, our entire source tree is
available on SourceForge via cvs. 
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/openhpi co openhpi will pull
the latest version.  From there ./bootstrap  ./configure  make
distcheck

Thanks in advance.

-
make[5]: Nothing to be done for install-exec-am'.
make[5]: Nothing to be done for install-data-am'.
make[5]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src/t'
make[4]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src/t'
make[3]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/src/t'
make[3]: Entering directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
make[4]: Entering directory /home/sdague/openhpi/openhpi-1.9.3/_build/src'
/bin/sh ../../mkinstalldirs
/home/sdague/tmp/am-dc-21838//home/sdague/openhpi/openhpi-1.9.3/_in
st/lib
 /bin/sh ../libtool --mode=install /usr/bin/install -c  libopenhpi.la
/home/sdague/tmp/am-dc-21
838//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpi.la
libtool: install: warning: relinking libopenhpi.la'
(cd /home/sdague/openhpi/openhpi-1.9.3/_build/src; /bin/sh ../libtool
--mode=relink gcc -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmiss
ing-declarations -Wstrict-prototypes -Wpointer-arith -Wformat=2
-Wformat-security -Wformat-nonliteral -Wno-format-y2k -Wcast-qual
-Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT -fexceptions -g -O2
-pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wpointer-arith -Wformat=2 -Wformat-security -Wformat-nonliteral
-Wno-format-y2k -Wcast-qual -Wcast-align -Werror -D_GNU_SOURCE -D_REENTRANT
-fexceptions -o libopenhpi.la -rpath
/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L../utils -version-info
10:3:9 -export-symbols ../../src/hpi.sym config.lo domain.lo event.lo
alarm.lo hotswap.lo lock.lo plugin.lo plugin_static.lo init.lo safhpi.lo
session.lo oHpi.lo ../utils/libopenhpiutils.la -lltdl -pthread
-lgthread-2.0 -lglib-2.0 -lm -lpthread -inst-prefix-dir /home/sdague/tmp
/am-dc-21838/)
echo { global:  .libs/libopenhpi.ver
 cat ../../src/hpi.sym | sed -e s/\(.*\)/\1;/  .libs/libopenhpi.ver
 echo local: *; };  .libs/libopenhpi.ver
 gcc -shared  .libs/config.o .libs/domain.o .libs/event.o .libs/alarm.o
.libs/hotswap.o .libs/lock.o .libs/plugin.o .libs/plugin_static.o
.libs/init.o .libs/safhpi.o .libs/session.o .libs/oHpi.o
-L/home/sdague/tmp/am-dc-21838//usr/lib  -Wl,--rpath
-Wl,/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L/usr/lib
-L/home/sdague/openhpi/openhpi-1.9.3/_build/utils -L/home/sdague/openhpi
/openhpi-1.9.3/_inst/lib -lopenhpiutils -lltdl -pthread -lgthread-2.0
-lglib-2.0 -lm -lpthread  -Wl,-soname -Wl,libopenhpi.so.1
-Wl,-version-script -Wl,.libs/libopenhpi.ver -o .libs/libopenh
pi.so.1.9.3
/usr/bin/ld: cannot find -lopenhpiutils
collect2: ld returned 1 exit status



-- 
__

Sean Dague   Mid-Hudson Valley
sean at dague dot netLinux Users Group
http://dague.net http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__


pgpcKB5Pfeo7H.pgp
Description: PGP signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool


Super-Víagra

2004-11-11 Thread Evan Mcgill
Generic cialis (Regalis), at cheap prices.
Most places charge $20, we charge $5. Quite a difference.

Cialis is known as a Super-Víagra or Weekend-Víagra because its effects start 
sooner and last much longer.
Shipped worldwide.

Your easy-to-use solution is here:   http://j-ust4u.com/free/?sash
-
The link below is for those who hate spam...
http://j-ust4u.com/rm.php?sash
-==-


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