Re: libtool 1.4 not passing linker directives

2001-10-04 Thread Ian Peters 

On Fri, 2001-10-05 at 02:21, Tim Van Holder wrote:
> On Fri, 2001-10-05 at 07:14, Ian Peters wrote:
> > Unfortunately, with libtool 1.4.x, I get this instead (after a much,
> > much longer time):
> > 
> > gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
> > [snip]
> > installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic
> > -Wl,-Bdynamic  ../libredcarpet/src/libredcarpet.a
> > [snip]
> > 
> > Conspicuously missing are the linker directives to be passed to gcc,
> > namely -Wl,-Bstatic and -Wl,-Bdynamic.  I do this to produce a binary
> > that is linked statically except for libc and the dynamic linker.
> 
> Clearly, they're not missing, but they do seem to have been
> overzealously grouped together at the start, with the change in results.

Whoops, you're right.  I didn't look at all of the command line close
enough, I just assumed they'd been stripped.

> > Is this a bug in libtool 1.4.x, or an undocumented change in behaviour? 
> > If so, is there some other way to accomplish the same goal?
> 
> I'd say a bug, since options libtool doesn't handle itself are moved
> around when they shouldn't be.

Suck, that was what I was afraid of.  Any workarounds?

-- 
Ian Peters
[EMAIL PROTECTED]


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

Re: libtool 1.4 not passing linker directives

2001-10-04 Thread Ian Peters 

On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote:
> What's bad is their position has been reordered. What version of
> libtool are you using? I take it you want all libraries between
> -Bstatic and -Bdynamic statically linked?

Forgot to say, this has been tested with libtool 1.4 and 1.4.2.

-- 
Ian Peters
[EMAIL PROTECTED]


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

Re: libtool 1.4 not passing linker directives

2001-10-04 Thread Ian Peters 

On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote:
> On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote:
> > Conspicuously missing are the linker directives to be passed to gcc,
> > namely -Wl,-Bstatic and -Wl,-Bdynamic.  I do this to produce a binary
> > that is linked statically except for libc and the dynamic linker.
> 
> Did you send the write output? I see -Wl,-Bstatic and -Wl,-Bdynamic in
> the output above.
> 
> What's bad is their position has been reordered. What version of
> libtool are you using? I take it you want all libraries between
> -Bstatic and -Bdynamic statically linked?

Whoops, you're right -- I only looked at the end of the output, I didn't
look closely enough to notice they'd just been reordered, not stripped.

Yes, the end goal is to have all of the libraries between the -Bstatic
and -Bdynamic linked statically, while keeping a dynamic binary against
libc and ld-linux.

-- 
Ian Peters
[EMAIL PROTECTED]


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

Re: libtool 1.4 not passing linker directives

2001-10-04 Thread Tim Van Holder 

On Fri, 2001-10-05 at 07:14, Ian Peters wrote:
> Unfortunately, with libtool 1.4.x, I get this instead (after a much,
> much longer time):
> 
> gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
> [snip]
> installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic
> -Wl,-Bdynamic  ../libredcarpet/src/libredcarpet.a
> [snip]
> 
> Conspicuously missing are the linker directives to be passed to gcc,
> namely -Wl,-Bstatic and -Wl,-Bdynamic.  I do this to produce a binary
> that is linked statically except for libc and the dynamic linker.

Clearly, they're not missing, but they do seem to have been
overzealously grouped together at the start, with the change in results.

> Is this a bug in libtool 1.4.x, or an undocumented change in behaviour? 
> If so, is there some other way to accomplish the same goal?

I'd say a bug, since options libtool doesn't handle itself are moved
around when they shouldn't be.



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

Re: libtool 1.4 not passing linker directives

2001-10-04 Thread libtool 

On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote:
> An application I work on has been calling libtool (through automake)
> with linker directives on the libtool line, around many of the libraries
> specified, like so (apologies if this wraps strangely, it's all one
> line):
> 
> /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -Wunused
> -Wmissing-prototypes -Wmissing-declarations   -o installer
> installer-distro.o installer-page.o installer-page-install.o
> installer-page-deps.o installer-page-finish.o installer-page-gdm.o
> installer-page-method.o installer-page-mirror.o
> installer-page-more-deps.o installer-page-proxy.o
> installer-page-select.o installer-page-start.o installer-state-machine.o
> installer-ui.o ../libredcarpet/src/libredcarpet.a
> ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic  -rdynamic
> -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint
> -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl  -lSM -lICE -lgtk
> -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd
> -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl
> /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk
> -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
> /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a
> /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff
> -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi
> -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic

I see -Wl,-Bstatic -rdynamic -Wl,-Bdynamic 

> With libtool 1.3.x, this resulted in the following call to gcc:
> 
> gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
> installer installer-distro.o installer-page.o installer-page-install.o
> installer-page-deps.o installer-page-finish.o installer-page-gdm.o
> installer-page-method.o installer-page-mirror.o
> installer-page-more-deps.o installer-page-proxy.o
> installer-page-select.o installer-page-start.o installer-state-machine.o
> installer-ui.o ../libredcarpet/src/libredcarpet.a
> ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic
> -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint
> -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk
> -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd
> -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl
> /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk
> -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
> /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgnomecanvaspixbuf.a
> /home/itp/imlib-1.9.10/gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff
> -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi
> -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic

Ditto.

> Unfortunately, with libtool 1.4.x, I get this instead (after a much,
> much longer time):
> 
> gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
> installer installer-distro.o installer-page.o installer-page-install.o
> installer-page-deps.o installer-page-finish.o installer-page-gdm.o
> installer-page-method.o installer-page-mirror.o
> installer-page-more-deps.o installer-page-proxy.o
> installer-page-select.o installer-page-start.o installer-state-machine.o
> installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic
 
> -Wl,-Bdynamic  ../libredcarpet/src/libredcarpet.a
  ^
> ../libgnometransfer/src/libgnometransfer.a -L/usr/lib -L/usr/X11R6/lib
> -L/usr/lib/lib /usr/lib/libgtkhtml.so /usr/lib/libgnomecanvaspixbuf.so
> /usr/lib/libbonobo.so /usr/lib/liboaf.so /usr/lib/libORBitCosNaming.so
> /usr/lib/libORBit.so /usr/lib/libIIOP.so /usr/lib/libORBitutil.so
> /usr/lib/libbonobox.so -lz -lXi -lXext -lX11 -lm -ldl /usr/lib/libgal.so
> /usr/lib/libgnomeprint.so /usr/lib/libgdk_pixbuf.so -ldl -lXi -lXext
> -lX11 -lm -lz /usr/lib/libglade-gnome.so -lXi -lXext -lX11 -lm -ldl -lz
> /usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so
> -lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl /usr/lib/libgdk_imlib.so
> -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm
> /usr/lib/libart_lgpl.so -lSM -lICE -ldl -lXi -lXext -lX11 -lm -ldl -lXi
> -lXext -lX11 -lm -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl
> -lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm
> /usr/lib/libaudiofile.so -lm -lm -lm -ldb1 -ldl /usr/lib/libgnet.so
> -lresolv -lnsl -ldl -ldl
> /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -ldl -lXi
> -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11
> -lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a
> /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a
> /usr/lib/libjpeg.so -ltiff /usr/lib/libungif.so -lX11 -lpng -lz -lm
> /usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl
> -lXi -lXext -lX11 -lm /

libtool 1.4 not passing linker directives

2001-10-04 Thread Ian Peters 

An application I work on has been calling libtool (through automake)
with linker directives on the libtool line, around many of the libraries
specified, like so (apologies if this wraps strangely, it's all one
line):

/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations   -o installer
installer-distro.o installer-page.o installer-page-install.o
installer-page-deps.o installer-page-finish.o installer-page-gdm.o
installer-page-method.o installer-page-mirror.o
installer-page-more-deps.o installer-page-proxy.o
installer-page-select.o installer-page-start.o installer-state-machine.o
installer-ui.o ../libredcarpet/src/libredcarpet.a
../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic  -rdynamic
-L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint
-lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl  -lSM -lICE -lgtk
-lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd
-laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl
/home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk
-lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
/home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a
/home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff
-lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi
-lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic

With libtool 1.3.x, this resulted in the following call to gcc:

gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
installer installer-distro.o installer-page.o installer-page-install.o
installer-page-deps.o installer-page-finish.o installer-page-gdm.o
installer-page-method.o installer-page-mirror.o
installer-page-more-deps.o installer-page-proxy.o
installer-page-select.o installer-page-start.o installer-state-machine.o
installer-ui.o ../libredcarpet/src/libredcarpet.a
../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic
-L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint
-lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk
-lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd
-laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl
/home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk
-rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
/home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgnomecanvaspixbuf.a
/home/itp/imlib-1.9.10/gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff
-lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi
-lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic

Unfortunately, with libtool 1.4.x, I get this instead (after a much,
much longer time):

gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
installer installer-distro.o installer-page.o installer-page-install.o
installer-page-deps.o installer-page-finish.o installer-page-gdm.o
installer-page-method.o installer-page-mirror.o
installer-page-more-deps.o installer-page-proxy.o
installer-page-select.o installer-page-start.o installer-state-machine.o
installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic
-Wl,-Bdynamic  ../libredcarpet/src/libredcarpet.a
../libgnometransfer/src/libgnometransfer.a -L/usr/lib -L/usr/X11R6/lib
-L/usr/lib/lib /usr/lib/libgtkhtml.so /usr/lib/libgnomecanvaspixbuf.so
/usr/lib/libbonobo.so /usr/lib/liboaf.so /usr/lib/libORBitCosNaming.so
/usr/lib/libORBit.so /usr/lib/libIIOP.so /usr/lib/libORBitutil.so
/usr/lib/libbonobox.so -lz -lXi -lXext -lX11 -lm -ldl /usr/lib/libgal.so
/usr/lib/libgnomeprint.so /usr/lib/libgdk_pixbuf.so -ldl -lXi -lXext
-lX11 -lm -lz /usr/lib/libglade-gnome.so -lXi -lXext -lX11 -lm -ldl -lz
/usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so
-lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl /usr/lib/libgdk_imlib.so
-ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm
/usr/lib/libart_lgpl.so -lSM -lICE -ldl -lXi -lXext -lX11 -lm -ldl -lXi
-lXext -lX11 -lm -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl
-lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm
/usr/lib/libaudiofile.so -lm -lm -lm -ldb1 -ldl /usr/lib/libgnet.so
-lresolv -lnsl -ldl -ldl
/home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -ldl -lXi
-lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11
-lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a
/home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a
/usr/lib/libjpeg.so -ltiff /usr/lib/libungif.so -lX11 -lpng -lz -lm
/usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl
-lXi -lXext -lX11 -lm /usr/lib/libgmodule.so -ldl /usr/lib/libglib.so
-ldl -lXi -lXext -lX11 -lm -luuid -lcrypt -lz -lutil

Conspicuously missing are the linker directives to be passed to gcc,
namely -Wl,-Bstatic and -Wl,-Bdynamic.  I do this to produce a binary
that is linked statically except for libc and the dynamic linker.

libtoo

postscript

2001-10-04 Thread Ian Peters 

I'm not sure what kind of list this is (I found the information at
www.gnu.org/directory/libtool.html), so I'm not currently subscribed. 
Please either send me subscription information, or CC me on replies. 
Thanks!

--
Ian Peters
[EMAIL PROTECTED]


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

More on C++ exception failure with gcc 3.0.1

2001-10-04 Thread Bob Friesenhahn 

This is a followup to my previous complaint that exceptions were not
working with CVS libtool, SPARC Solaris 2.6, and gcc 3.0.1.  I suspect
that this may be due to a compiler bug.

I performed a trivial C++ exception test to see if exceptions were
working.  I compiled the test by handl. The test worked.  I then
included the library headers from my package, and the test still
worked.  A more sophisticated test in which I threw an exception from
a function failed to work.

Reports this:
Program received signal SIGSEGV, Segmentation fault.
0xeed6e274 in ?? () at
/home/bfriesen/src/gnu/gcc-3.0.1/libstdc++-v3/libsupc++/vec.cc:52
   from /usr/local/lib/libstdc++.so.3
52  uncatch_exception::uncatch_exception ()

It doesn't seem that any code in the method was executed.  The title
on the top of this source module is "New abi Support".

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen


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

[ÃÊû°­¿¬ È«º¸] ±× ´©°¡ °¨È÷ Çй®Àº ¾ø¾ú´Ù°í ¿ÜÃÆ´ø°¡?

2001-10-04 Thread ÃÊû°­¿¬ 
Title: ¢À ½ÅÁö½ÄÀÎ ÃÊû °­¿¬È¸ ¢À




¾È³çÇϼ¼¿ä. º»¸ÞÀÏÀº °­¿¬È¸ È«º¸¸¦ À§ÇÏ¿© 1ȸ¼º ¸ÞÀÏÀÌ¸ç ¸ÞÀÏ È¨ÆäÀÌÁö¿Í °Ô½ÃÆÇ¿¡¼­ 
¼öÁýµÈ°ÍÀÔ´Ï´Ù
¢À ½ÅÁö½ÄÀÎ ÃÊû 
°­¿¬È¸ ¢À  
Á¤º¸È­ ½Ã´ë¿¡ ÁöÀû 
È£±â½ÉÀÌ ¸¹Àº ´ç½Å !!½ÅÁö½ÄÀÎ ÃÊû 
¹«·á °­¿¬È¸¿¡ ´ÔÀ» ÃÊ´ëÇÏ°íÀÚ ÇÕ´Ï´Ù. 
Áö±Ý±îÁö ±× ´©°¡ 
°¨È÷ Çй®Àº ¾ø¾ú´Ù°í 
¿ÜÃÆ´ø°¡? Çй®À̶õ? - »ç¹°ÀÇ ÀÌÄ¡¿Í º»ÁúÀ» ±Ô¸íÇÏ´Â 
°ÍÀÌ´Ù.   
¹°ÁúÀÇ ÃÖ¼Ò´ÜÀ§ÀÎ ¿øÀÚ..  ¿øÀÚ ¼ÓÀÇ ÀüÀÚ´Â ¹«½¼ ¿¡³ÊÁö·Î µ¹¾Æ°¡°í Àִ°¡?
½ÅÇÐÀ̶õ? - ½Å¿¡ ´ëÇØ ³íÇÏ´Â 
Çй®?   ±×·³ 
½ÅÀÇ º»ÁúÀº 
¹«¾ùÀΰ¡?  ½ÅÀ» ¾ËÁö 
¸øÇϴµ¥ ¾î¶»°Ô ½Å¿¡ ´ëÇØ ³íÇÒ ¼ö Àִ°¡?
Çй®°ú ½ÅÀ» 
Ãß±¸ÇÏ´Â Àΰ£Àº °ú¿¬ 
¾î¶² Á¸ÀçÀΰ¡?   ¶Ç 
Àΰ£ÀÇ º»Áú°ú 
¼Ó¼ºÀº °ú¿¬ 
¾î¶°ÇÑ°¡?Àΰ£ÀÇ 
»ç°íÀÇ ÆÇ´Ü ±âÁØÀº °ú¿¬ Á¤È®ÇÑ °ÍÀΰ¡?  
Áö±Ý±îÁö Áø¸®¶ó°í 
¹Ï¾î¿Ô´ø ¡Á¡Á¡Á  »ý! ÀÚ! ÇÊ! ¸ê!
21¼¼±â ¼¼°èÀÇ 
ÃÖ÷´Ü ¹ÙÀÌ¿À °úÇÐÀڵ鿡 ÀÇÇØ ±×°ÍÀÌ °ÅÁþÀÓÀÌ ¹àÇôÁö°í,  - 
À¯ÀüÇÐÀÚµé : 20³â³» Àΰ£ ¼ö¸í 40»ì ½Ã´ë¿Â´Ù - ½ºÆ÷Ã÷ Á¶¼± 1992. 9. 
19.  Á×À½Àº 
ÀÚ¿¬¿¡ ¿ªÇàÇÏ´Â 
°ÍÀÌ´Ù.  Àΰ£Àº 
¸»ÇÏÀÚ¸é ±× ÀÚü°¡ ÀÚµ¿ º¸¼ö 
ÀÚÄ¡ÀÌ´Ù.(³ëº§ 
È­Çлó ¼ö»óÀÚÀÎ ¹Ì±¹ÀÇ ¶óÀ̳ʽº Æú¸µ ¹Ú»ç)
 - 
ºÒ·ÎºÒ»ç À¯ÀüÀÚ ¹ß°ß ¹ßÇ¥ : ¹Ì±¹ ·Î½º ±³¼ö  1999³â 7¿ù 5ÀÏ
 - 
¿ì¸® ¸ö ¼Ó¿¡ ¿µ»ýÀ» ±â¾ïÇÏ´Â ¼¼Æ÷µéÀÌ 
ÀÖ´Ù   < 
1991³â 8¿ù ¹Ì±¹ ABC TV ¹æ¼ÛÀÇ ºÒ»ç¿¡ °üÇÑ TV Åä·Ð>¼±Áø ÷´Ü Çй®Àº ¿ÏÀü Áø¸®¸¦ Ãß±¸ ÅëÇØ ºÒ·ÎºÒ»ç(ÝÕÖÕÝÕÞÝ)¸¦ ¸ñÇ¥·Î 
¹ßÀüµÇ°í 
ÀÖ½À´Ï´Ù.
º» °­¿¬È¸´Â 
ºÒ·ÎºÒ»ç ±× Á¤»ó¿¡¼­ ¹Ù¶óº» 
¿ÏÀüÇÑ Çй®, Á¾±³, °úÇÐÀ»  ¿©·¯ºÐµé¿¡°Ô ÀüÇØ µå¸®°íÀÚ ÇÕ´Ï´Ù. 

ÁøÃëÀûÀÌ¸ç ¿­¸° ¸¶À½À¸·Î Áö½ÄÀ» °¥±¸ÇÏ´Â À̵éÀÇ ¸¸³²ÀÇ ½Ã°£ÀÌ µÇ½Ã±æ 
¹Ù¶ø´Ï´Ù.
ÀÏ 
 ½Ã : 2001³â 10¿ù 6ÀÏ ¿ÀÈÄ 3½Ã
Àå 
 ¼Ò : ºÎõ ½Ã¹Î ȸ°ü ¼Ò°­´ç
 



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

Comments in -export-symbols file

2001-10-04 Thread Kevin Ryde 

Maybe this is a dumb question, but is it possible, by which I mean
portable, to put comments in the symbol file used with
-export-symbols?

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

ar cru piecewise linking of same named objects

2001-10-04 Thread Kevin Ryde 

I think I've struck a bit of a problem trying the cvs libtool with
GMP.  GMP has some object files with the same name, like mpz/random.lo
and mpn/random.lo.  On vax-dec-ultrix4.5, libtool decides the command
line limit is 3073, and does the final libgmp library link in two
pieces.  Unfortunately one random.lo happens to be in the first piece
and one in the second.  The library construction uses "ar cru" for
both pieces and the second therefore replaces the first, whereas I
hoped to have both in the library.

Leaving aside the question of whether same-named objects are a good
idea in general, perhaps libtool should be using "ar q" or "ar qs" or
some such for the second and subsequent pieces.

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

Re: Darwin patches?

2001-10-04 Thread scott hutinger 

On Fri, 5 Oct 2001, Max Horn wrote:
[...]
> 
> At 1:35 Uhr +0200 22.09.2001, Max Horn wrote:
> >1) with regard to dlpreopen, there is yet another quoting problem. 
> >The libtool file generated from HEAD-cvs contains three lines like 
> >this:
> >
> >global_symbol_to_c_name_address="sed -n -e 's/^: \([^ ]*\) \$/ 
> >{\\"\1\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \([^ ]*\) \([^ ]*\)\$/ 
> >{\"\2\", (lt_ptr) \&\2},/p'"
> 
> 
> And that is exaclty why cdemo fails.
> 

Ok, got the point exactly.  Normally I stay away from 'zsh' and "zsh".

thanks,
scott

> 
> Max
> 



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

Re: Darwin patches?

2001-10-04 Thread Max Horn 

At 17:39 Uhr -0500 04.10.2001, scott hutinger wrote:
>On Fri, 5 Oct 2001, Max Horn wrote:
>
>>  >Ok, cdemo tests fail.  What are the requirements from admin for
>>  >modification to cdemo if needed?  Sorry I have to ask, sometimes people
>>  >have various reasons for not allowing specific modifications.
>>
>>  The problem is not in cdemo, this is a test, and it fails for valid
>>  reasons on Darwin - namely, it is the zsh quoting issue strikin once
>>  more. I reported this before, but I am not the one to fix this in
>>  libtool's source - libtool's source ain't easy to understand, yet to
>>  modify in a manner that doesn't break many other systems.
>
>Yes, I was asking what the requirements are for regression testing
>modifications if need be.  Normally this isn't a good thing, and causes
>problems all around for some time (new branch until working again).  But
>in some instances the modifications are small enough not to pull a domino
>effect.  I think everyone knows that anyway.

I understood you were asking for a change to a regression test. And I 
think I explained why this would *not* be a good thing! There is an 
actual problem in libtool, caused by zsh on Darwin. Changing the 
regression test will not fix the problem, only make the regression 
test useless. after all, regression tests are there to flag such 
problems.

So: leave cdemo alone. Rather, try to fix the *source* for the 
problem. Citing an older mail:


At 1:35 Uhr +0200 22.09.2001, Max Horn wrote:
>1) with regard to dlpreopen, there is yet another quoting problem. 
>The libtool file generated from HEAD-cvs contains three lines like 
>this:
>
>global_symbol_to_c_name_address="sed -n -e 's/^: \([^ ]*\) \$/ 
>{\\"\1\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \([^ ]*\) \([^ ]*\)\$/ 
>{\"\2\", (lt_ptr) \&\2},/p'"


And that is exaclty why cdemo fails.


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

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

Re: Darwin patches?

2001-10-04 Thread scott hutinger 

On Fri, 5 Oct 2001, Max Horn wrote:

> >Ok, cdemo tests fail.  What are the requirements from admin for
> >modification to cdemo if needed?  Sorry I have to ask, sometimes people
> >have various reasons for not allowing specific modifications.
> 
> The problem is not in cdemo, this is a test, and it fails for valid 
> reasons on Darwin - namely, it is the zsh quoting issue strikin once 
> more. I reported this before, but I am not the one to fix this in 
> libtool's source - libtool's source ain't easy to understand, yet to 
> modify in a manner that doesn't break many other systems.

Yes, I was asking what the requirements are for regression testing
modifications if need be.  Normally this isn't a good thing, and causes
problems all around for some time (new branch until working again).  But
in some instances the modifications are small enough not to pull a domino
effect.  I think everyone knows that anyway.

> 
> 
> Note that it is *not* sufficient to fix the files like ltmain.sh, 
> libtool, ltconfig etc. - these files are generated from other 
> meta-source files.
> 
Yes, sort of too bad eh?
> 
> You should also look at the mailing list archives for some recent 
> posts by me on this and other issues.
> 

I will,
thanks,
scott

> 
> Max
> 


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

Re: Darwin patches?

2001-10-04 Thread Max Horn 

>Ok, cdemo tests fail.  What are the requirements from admin for
>modification to cdemo if needed?  Sorry I have to ask, sometimes people
>have various reasons for not allowing specific modifications.

The problem is not in cdemo, this is a test, and it fails for valid 
reasons on Darwin - namely, it is the zsh quoting issue strikin once 
more. I reported this before, but I am not the one to fix this in 
libtool's source - libtool's source ain't easy to understand, yet to 
modify in a manner that doesn't break many other systems.


Note that it is *not* sufficient to fix the files like ltmain.sh, 
libtool, ltconfig etc. - these files are generated from other 
meta-source files.


You should also look at the mailing list archives for some recent 
posts by me on this and other issues.


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

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

Re: Darwin patches?

2001-10-04 Thread scott hutinger 

On Thu, 4 Oct 2001, Max Horn wrote:

> >  > The reason is,
> >>
> >>  [drawin1.[0-2]]] is a bit behind, since Darwin is at 1.4.1 as of October
> >>  1st.  Although < 1.4.0 is a major change in some instances, although not
> >>  so much with libtool.
> 
> There is a good reason for this check - it *deliberatly* checks for 
> darwin 1.0 - 1.2, because those are different in many aspects from 
> 1.3/1.4. Those are handled in other places, though.

I think a portion of the problem, is that the full patches don't live at
home yet, which had me patching before I found all the other patches.  I
noticed only 1.0..1.2 in the changelog, which didn't exist in other
places.  The PPC linux kernel is basically the same.

I have now seen the light :-)

> 
> 
> >  >
> >>  I asked the Darwin group why they are just local to the filesystem.
> >
> >Okay.  Keep us posted.
> >
> >There is one patch against libtool for the benefit of Darwin, that I
> >have had to rejected because it causes regressions for most other
> >platforms.  You should be able to find the thread in the list archives.
> 
> That patch is actually bad even on darwin. As Christoph Pfisterer and 
> I posted here various time (but sadly, there never was a reply), 
> there seems to be a bit more fundamental libtool issue regarding 
> conveniance libs. The -all_load flag just doesn't do it, and libtool 
> has this habit of listing convenience libs twice on the command line 
> used to invoke the linker, causing loads of "multiple definitions" 
> errors
> 
> 

Ok, cdemo tests fail.  What are the requirements from admin for
modification to cdemo if needed?  Sorry I have to ask, sometimes people
have various reasons for not allowing specific modifications.

thanks,

scott

> 
> >
> >Also there is a long standing problem with the way zsh echo handles
> >backslashes that I haven't had the time to look into.  Fixing this
> >would make life for libtool on darwin a whole lot easier...
> 
> Certainly!
> 
> 
> Max
> 




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

Re: Darwin patches?

2001-10-04 Thread Max Horn 

>  > The reason is,
>>
>>  [drawin1.[0-2]]] is a bit behind, since Darwin is at 1.4.1 as of October
>>  1st.  Although < 1.4.0 is a major change in some instances, although not
>>  so much with libtool.

There is a good reason for this check - it *deliberatly* checks for 
darwin 1.0 - 1.2, because those are different in many aspects from 
1.3/1.4. Those are handled in other places, though.


>  >
>>  I asked the Darwin group why they are just local to the filesystem.
>
>Okay.  Keep us posted.
>
>There is one patch against libtool for the benefit of Darwin, that I
>have had to rejected because it causes regressions for most other
>platforms.  You should be able to find the thread in the list archives.

That patch is actually bad even on darwin. As Christoph Pfisterer and 
I posted here various time (but sadly, there never was a reply), 
there seems to be a bit more fundamental libtool issue regarding 
conveniance libs. The -all_load flag just doesn't do it, and libtool 
has this habit of listing convenience libs twice on the command line 
used to invoke the linker, causing loads of "multiple definitions" 
errors



>
>Also there is a long standing problem with the way zsh echo handles
>backslashes that I haven't had the time to look into.  Fixing this
>would make life for libtool on darwin a whole lot easier...

Certainly!


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

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

Re: _LT_AC_TAGCONFIG versus Cray sed

2001-10-04 Thread Kevin Ryde 

[EMAIL PROTECTED] writes:
> 
> If you replace the delimiter with a character other than "/", does the
> sed command work?

Yes, colons worked in last nights build.



--- libtool.m4.old	Thu Oct  4 01:40:53 2001
+++ libtool.m4	Thu Oct  4 01:42:27 2001
@@ -1446,7 +1446,7 @@
   for tagname in $tagnames; do
 IFS="$lt_save_ifs"
 # Check whether tagname contains only valid characters
-case `$echo "X$tagname" | $Xsed -e 's/[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]//g'` in
+case `$echo "X$tagname" | $Xsed -e 's:[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]::g'` in
 "") ;;
 *)  AC_MSG_ERROR([invalid tag name: $tagname])
 	;;

Re: Darwin patches?

2001-10-04 Thread Gary V. Vaughan 

On Wed, Oct 03, 2001 at 05:08:31PM -0500, scott hutinger wrote:
> I thought you might be able to help me with this question.
> 
> Currently Apple/Darwin keeps some libtool files in their
> /usr/share/libtool that under a build of berkeleydb for OpenOffice, I copy
> those files to the berkelydb before configuration of db-x.
> 
> I was wondering if anyone from the Darwin group or Apple ever sends in
> patches?  Possibly they might not get accepted for some reason?  I would
> prefer to get berkelydb patched and over with, instead of tracking it all
> the time.

Sure.  From the ChangeLog in HEAD:

2001-09-06  Gary V. Vaughan  <[EMAIL PROTECTED]>

From Daniel Johnson <[EMAIL PROTECTED]>:
* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [darwin*]: Move from GNU
ld section to non-GNU ld section.

...

2001-09-02  Christopher Pfisterer <[EMAIL PROTECTED]>

* libtool.m4, ltmain.in: Linker flag and version numbering fixes
for darwin.

...

2001-08-05  Gary V. Vaughan  <[EMAIL PROTECTED]>

From Brad <[EMAIL PROTECTED]>:
* libtool.m4 (archive_cmds) [darwin, newsos, sysv4]: Replace
1.3 era $linkopts references with $linker_flags.

> The reason is, 
> 
> [drawin1.[0-2]]] is a bit behind, since Darwin is at 1.4.1 as of October
> 1st.  Although < 1.4.0 is a major change in some instances, although not
> so much with libtool.
> 
> I asked the Darwin group why they are just local to the filesystem.

Okay.  Keep us posted.

There is one patch against libtool for the benefit of Darwin, that I
have had to rejected because it causes regressions for most other
platforms.  You should be able to find the thread in the list archives.

Also there is a long standing problem with the way zsh echo handles
backslashes that I haven't had the time to look into.  Fixing this
would make life for libtool on darwin a whole lot easier...

Cheers,
Gary.
-- 
  ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk   ,_())
  / )=  GNU Hacker  http://www.gnu.org/software/libtool  \'  `&
`(_~)_  Tech' Authorhttp://sources.redhat.com/autobook   =`---d__/

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

libtool 1.4.2 + darwin problem

2001-10-04 Thread Lars J. Aas 

On Tue, Sep 11, 2001 at 05:06:51AM +0100, Gary V. Vaughan wrote:
: I am pleased to announce the release of GNU Libtool 1.4.2, which now

I haven't investigated this problem that thorough, but on a
"powerpc-apple-darwin1.3.7" system (an iBook) I had to change the
$archive_cmds variable (in libtool.m4 for libtool 1.4.2 (serial 46))
from

archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle || echo -dynamiclib) 
$allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags -install_name 
$rpath/$soname $verstring'

to

archive_cmds='$nonopt $(test x$module = xyes && echo -bundle || echo -dynamiclib) 
$allow_undefined_flag -o $lib $libobjs $linker_flags -install_name $rpath/$soname 
$verstring'

to get around a problem with the final linker line having duplicated the
list of convenience libraries.  $libobjs contained both the .los and .las,
and $deplibs contained all the .las, so the link stopped with duplicate
symbol errors.  I also had to remove the "s to get around a weird quoting
problem.

Is this a known issue?  A local problem?  libtool is used in combination
with Autoconf 2.52 and Automake 1.5.

  Lars J

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

Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6

2001-10-04 Thread libtool 

On Thu, Oct 04, 2001 at 09:06:35AM -0500, Bob Friesenhahn wrote:
> On Thu, 4 Oct 2001 [EMAIL PROTECTED] wrote:
> > > Has anyone else seen this problem?  Is it due to libtool?
> > 
> > Have you tried generating a small test program with exceptions to
> > determine if GCC is the culprit? I cannot imagine anything inherent in
> > libtool that would cause a problem. Are both versions of GCC built the
> > same (i.e. with GNU as/ld)?
> 
> Both versions use Solaris 'as' and Solaris 'ld'.  Tests with simple
> exceptions in a small stand-alone program show that exceptions do
> work. A somewhat larger test program crashes in libstdc++
> (libsupc++/vec.cc:52) so perhaps this is a compiler library issue
> unrelated to libtool.

Sorry, cannot be of much additional help. You might want to try the
3.0 branch from CVS for GCC (3.0.2 will be released soon) or examine
how libtool builds with 2.95 and 3.0 to determine if it does anything
differently (I'm not aware that it does).

If it is a bug in GCC 3.0.1, then it's a regression against 2.95.x and
will most likely get high priority.

-- 
albert chin ([EMAIL PROTECTED])

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

Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6

2001-10-04 Thread Bob Friesenhahn 

On Thu, 4 Oct 2001 [EMAIL PROTECTED] wrote:
> > Has anyone else seen this problem?  Is it due to libtool?
> 
> Have you tried generating a small test program with exceptions to
> determine if GCC is the culprit? I cannot imagine anything inherent in
> libtool that would cause a problem. Are both versions of GCC built the
> same (i.e. with GNU as/ld)?

Both versions use Solaris 'as' and Solaris 'ld'.  Tests with simple
exceptions in a small stand-alone program show that exceptions do
work. A somewhat larger test program crashes in libstdc++
(libsupc++/vec.cc:52) so perhaps this is a compiler library issue
unrelated to libtool.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



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

Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6

2001-10-04 Thread libtool 

On Wed, Oct 03, 2001 at 09:27:41PM -0500, Bob Friesenhahn wrote:
> ImageMagick has been using CVS libtool.  With gcc 2.95.2, C++
> exceptions work fine under Solaris 2.6.  With gcc 3.0.1, C++
> exceptions are not being caught, causing the program to core dump.
> 
> Has anyone else seen this problem?  Is it due to libtool?

Have you tried generating a small test program with exceptions to
determine if GCC is the culprit? I cannot imagine anything inherent in
libtool that would cause a problem. Are both versions of GCC built the
same (i.e. with GNU as/ld)?

-- 
albert chin ([EMAIL PROTECTED])

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