Super-VÃagra
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
libtool 1.5.6 still not supporting make distcheck
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
Re: TODO
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
Re: TODO
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: License of m4/ltoptions.m4
"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: License of m4/ltoptions.m4
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
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: TODO
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 ' 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
未承諾広告※5000円で開業してみませんか
$BHNGd5Bz9-9p"((B $B$4LBOG$JJ}$O:o=|$7$F$/[EMAIL PROTECTED](B $BEv9-9p$r$K$"$j$^$;$s!*!!(B $B%S%8%M%9$NE4B'$G$9!##1HVEEh$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
Aloha Casino Online!
Aloha! Enjoy island style entertainment with these hot new promotional offers: $300 match deposit bonus - bonus code X3DAW at casino's cashier. $10 free, no deposit necessary - bonus code FR1EE at casino's cashier. Vacation at Aloha Casino! 50 amazing games - 24/7 customer support - SafeBet certification Visit: http://www.alohacasino.biz Mahalo, Billy Bob No thanks: http://www.alohacasino.biz/u/ ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
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
