[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Update of sr #110901 (group libtool): Status: In Progress => Done Open/Closed:Open => Closed ___ Follow-up Comment #22: I am happy to hear that! I have commited hopefully the l

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #21, sr #110901 (group libtool): Looks nice! The only correction I can suggest: for consistency either add : "${COMSPEC=cmd}" to the start of the libtool files (possibly somewhere executed only on MinGW) or replace configure test with simple 'cmd' instead of ${COMSPEC-cmd}. Ot

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #20, sr #110901 (group libtool): Thank you again for your suggested changes! The update has been applied to the development branch, so I will close this, if it looks good. https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=7efc1891083cd53ea3961454d95f37c

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #19, sr #110901 (group libtool): [comment #16 comment #16:] > [comment #12 комментарий №12:] >> [comment #10 comment #10:] >>> Looks like MSys is still in (very inactive) use. >>> The project page has two years old activity. >> Could you link the project page here? >> > > Pro

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #18, sr #110901 (group libtool): Proper powershell command for path conversion: powershell -command Write-Output \"some_path\" ___ Reply to this item at:

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #17, sr #110901 (group libtool): Additional (but the slowest) ways is using powershell instead of cmd powershell -command echo some_path But it is much slower than cmd. ___ Reply to this item at:

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #16, sr #110901 (group libtool): [comment #12 комментарий №12:] > [comment #10 comment #10:] >> Looks like MSys is still in (very inactive) use. >> The project page has two years old activity. > Could you link the project page here? > Probably the most current valid link is h

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #15, sr #110901 (group libtool): I pushed a patch that should cache if cygpath is present with a simple check for the help message. If the check is successful, func_convert_core_msys_to_w32_with_cygpath will be used, but if it is not, the previous implementation will be used, fun

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #14, sr #110901 (group libtool): [comment #13 comment #13:] >> This sounds fine to me. Could you write a patch for this, or specify the ENV >> variable and parts of path conversion that you would like bypassed? > > > I updated > https://github.com/mitchcapper/libtool/compare/ad

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Additional Item Attachment, sr #110901 (group libtool): File name: libtool-37ce24a-libtool Add msys bypass path conversion env var LIBTOOL_MSYS_NO_PATH_CONVERSION.patch Size: 1KiB

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #13, sr #110901 (group libtool): > This sounds fine to me. Could you write a patch for this, or specify the ENV > variable and parts of path conversion that you would like bypassed? I updated https://github.com/mitchcapper/libtool/compare/add_bypass_path_conversion_opt and ha

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Update of sr #110901 (group libtool): Status:Done => In Progress Open/Closed: Closed => Open ___ Follow-up Comment #12: [comment #10 comment #10:] > Looks like MSys is sti

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #11, sr #110901 (group libtool): I would still highly recommend adding a bypass ENV var as its fairly straightforward to just use posix style compat windows paths. Giving the user (or software) the ability to turn it off would seem beneficial. Libtool is quite slow on windows

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #10, sr #110901 (group libtool): Looks like MSys is still in (very inactive) use. The project page has two years old activity. Some large projects, like libcurl, are still testing for the original MSys/MinGW. I wouldn't drop support for now, as it is easy to check for 'cygpath' a

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #9, sr #110901 (group libtool): [comment #8 comment #8:] > [comment #7 комментарий №7:] >> I have applied a patch for this issue on the development branch [1], which >> should migrate to master after more testing. If this does not seem to fix >> it, I will reopen. >> >> [1]https

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #8, sr #110901 (group libtool): [comment #7 комментарий №7:] > I have applied a patch for this issue on the development branch [1], which > should migrate to master after more testing. If this does not seem to fix it, > I will reopen. > > [1]https://cgit.git.savannah.gnu.org/cgi

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Update of sr #110901 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #7: I have applied a patch for this issue on the development

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #6, sr #110901 (group libtool): Sorry, I forgot to add one way to slightly increase performance as this does seem msys specific would be to call cygpath as we do elsewhere. That would reduce it from 8 to 2 processes spawned every time I believe. ___

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

ENV var so nothing benefits from the fix initially. In fact due to the nature of the bug no project will likely implement the flag in their build process (unless they used the forward slash notation with relative which would ensure msys escaping would not happen. Instead this would be a user level flag

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #4, sr #110901 (group libtool): This is a similar report to both of the following: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949 Maybe an update to libtool's documentation should be made, since this has

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 30 Nov 2023 22:45, Nick Bowler wrote: > Interestingly the libtool manual also says "If [libtool] can't infer a > tag, then it defaults to the configuration for the C language", which is > clearly not the case (it seems what actually happens is that if libtool > can't infer a tag then it exits

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #3, sr #110901 (project libtool): OK! Sorry for not investigating further, once I found the mailing list thread that seemed like it terminated with the proper fix (and verifying it fixed it for me) I stopped debugging the issue. It is now clear. I think this relates to the MSYS

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #2, sr #110901 (project libtool): [(Ошибка - не найдено)] When starting any program under MSYS (and MSYS2), the MSYS[2] checks whether the lunched program is linked with msys-*.dll. If program is linked with this DLL then the program expects POSIX-like environment so no path tra

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #1, sr #110901 (project libtool): [(Ошибка - не найдено)] No, it's wrong. See https://sourceware.org/pipermail/cygwin/2021-June/248814.html ___ Reply to this item at: ___

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

URL: <https://savannah.gnu.org/support/?110901> Summary: libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug Group: GNU Libtool Submitter: mitchc Submitted: Wed 19 Jul 2023 07:23:17

Request for bug submission clarification

Hello, There is a bit of confusion in bug submissions. There are at least 3 ways I could find being used: - debbugs - bug-libt...@gnu.org - https://savannah.gnu.org/support/?group=libtool Although the first 2 are pretty similar, submitting bugs to the mailing list don't make them appe

Re: bug#48088: libtool hardcodes native (cross-)compiler, incorrect when using libtool as cross-compiler

ile. It seems like ‘we’ will have to patch libtomsmath appropriately. I might eventually look into the issue, but probably not in the near future. Let's stop CC'ing libtool@gnu.org; this issue isn't really a bug in libtool. Greetings, Maxime. signature.asc Description: This is a digitally signed message part

Re: bug#48088: libtool hardcodes native (cross-)compiler, incorrect when using libtool as cross-compiler

Hi Maxime, Maxime Devos skribis: > $ cat $(guix build libtool)/bin/libtool > Some relevant output: [...] > However, during linking, (at least during the compilation of libtomsmath > IIRC), > libtool uses LTCC instead. Thus, when a package X has libtool in > native-inputs, The ‘libtool’ scr

libtool.m4 bug (spaces detection in compiler's output after -L/-R)

Hi! There is probaby a bug in 'm4/libtool.m4' that prevents correct detection of all the library paths provided by compiler (comparison is always FALSE). Here is a small patch: diff -ruN orig/m4/libtool.m4 patched/m4/libtool.m4 --- orig/m4/libtool.m4   2019-04-18 16:57:12.48750

Re: Potential bugfix for bug#21455: Bug while cross-compiling multiple libtool-based packages ...

Ping ? On Sun, 2015-10-18 at 15:41 +0200, Joakim Tjernlund wrote: > While googling for a fix for bug#21455, >  http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html , > I came across: >   > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/

Potential bugfix for bug#21455: Bug while cross-compiling multiple libtool-based packages ...

While googling for a fix for bug#21455, http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html , I came across: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath.patch?id=release-2010.12 This appear to be the correct fix

Libtool bug #18325

Hello, Bug #18325 has been reported 8 months ago with no reply from Libtool authors: http://lists.gnu.org/archive/html/bug-libtool/2014-08/msg2.html Can someone please take position on a possible resolution? Regards, Gregory ___ https

Re: bug#18910: GNU Libtool-2.4.3 released [stable]

Hi Pavel, Sorry the lists are being slow this weekend :( > On Oct 30, 2014, at 1:06 PM, Pavel Raiskup wrote: > > Thanks for the release, Gary and all! > > On Monday 27 of October 2014 21:44:02 Gary V. Vaughan wrote: >> - Fix a long-standing bug when using libtoolize

Automake, Libtool and AM_PROG_AR (was: Re: bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR)

References: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11401> <http://lists.gnu.org/archive/html/automake/2012-05/msg00012.html> On 05/11/2012 01:37 PM, Stefano Lattarini wrote: > On 05/04/2012 09:19 PM, Mike Frysinger wrote: >> On Friday 04 May 2012 03:20:10 Peter Rosin

Re: bug#9257: configure errors after upgrade to libtool 2.4

Julien ÉLIE writes: > It seems to be related to: > SED='`$ECHO "$SED" | $SED "$delay_single_quote_subst"`' > Xsed='`$ECHO "$Xsed" | $SED "$delay_single_quote_subst"`' > macro_version='`$ECHO "$macro_version" | $SED "$delay_single_quote_subst"`' > macro_revision='`$ECHO "$macro_revision" | $SED "

Re: bug#9257: configure errors after upgrade to libtool 2.4

Hi all, Following an issue reported in: https://lists.gnu.org/archive/html/bug-libtool/2011-08/msg00012.html I found out that upgrading from libtool 2.2.6b to libtool 2.2.8 already triggers the error off. Would it be related to the $Xsed -> $SED switch? Is there something that should be ta

Libtool 2.2.10 Linux -> windows cross compile bug?

ceware.org/binutils/docs/ld/WIN32.html I should be able to link directly to a Windows dll using -lxxx. If I try that libtool complains that it cannot find the library. The libraries are actually there and are named xxx.dll. If I rename the the file to libxxx.dll than libtool finds the library. Is thi

Re: lt_dlerror 'file not found' bug

nce that it becomes "magically" dlopenable, although all > files remain on the same place as before. I don't have anything to add, only that this bug is really, really irritating. We've suffered through it with Guile for quite some time now. So go Matěj go, you

Re: lt_dlerror 'file not found' bug

uses shared modules will usually fail the preloader. The preloader likely also pretends that the "file is not there" if there is no preloadable module. The bug you are encountering was reported at least two years ago. It is still awaiting a good idea for how to fix it. There n

lt_dlerror 'file not found' bug

Obviously it is the error from the last attempt, that usually is that 'file not found' case. The error that matters is therefore overwritten by every subsequent error. I have briefly tested the git version, the bug is still there. I would like to contribute to fix this bug. Could you pleas

Re: Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

* Rafał Mużyło wrote on Wed, Jul 29, 2009 at 09:15:27PM CEST: > On Wed, Jul 29, 2009 at 07:22:54PM +0200, Ralf Wildenhues wrote: > > > > Libtool 2.2.6 allows you to specify global or local visibility with the > > lt_dladvise_local and lt_dladvise_global functions. > > > Just to make sure: that was

Re: Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

On Wed, Jul 29, 2009 at 07:22:54PM +0200, Ralf Wildenhues wrote: > > unixODBC bundles libtool, as it patches it. It does that, > > cause LT_GLOBAL in dlopen call causes a problem when > > unixODBC is used by Perl::ODBC module. > > Libtool 2.2.6 allows you to specify global or local visibility with

Re: Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

Hello Rafał, thanks for the report. * Rafał Mużyło wrote on Wed, Jul 29, 2009 at 02:06:48PM CEST: > Following problem is of only limited interest for me, > but I think some input from libtool people could be useful there. FWIW, this is . > unixODBC bundles libtool

Gentoo bug #249617 - problem with libtool, perl or unixODBC ?

Following problem is of only limited interest for me, but I think some input from libtool people could be useful there. unixODBC bundles libtool, as it patches it. It does that, cause LT_GLOBAL in dlopen call causes a problem when unixODBC is used by Perl::ODBC module. Now, my question is: is thi

Re: Cannot link correct libltdl.so. Is it a bug?

her due to your previous warnings where you didnt setup build env fully enough, or the package itself sucks and uses -L paths. or you're hitting a bug in libtool having to do with relinking. use a --prefix pointing to your development root to workaround the issue. if you have cross-comp

Cannot link correct libltdl.so. Is it a bug?

lrwxrwxrwx1 tooladm toolsup16 Apr 15 2008 /tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so.3 -> libltdl.so.3.1.4* -rwxr-xr-x1 tooladm toolsup 32136 Apr 1 2008 /tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so.3.1.4* Can someone tell me how to run configure s

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...: To answer Bob's previous question, I generally upgrade any project I'm building to use libtool 1.5.latest, so right now I'm using 1.5.26. Maybe you should be trying 2.2 since support for the Solar

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

On Fri, 21 Mar 2008, Tim Mooney wrote: What version of Sun C++ are you using? The C++ from Workshop 12 with patches applied: $CC -V CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25 % CC -V CC: Sun C++ 5.9 SunOS_i386 Patch 124864-02 2007/12/18 To answer Bob's previous question, I gener

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...: On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney wrote: I think I have discovered a bug in libtool's link behavior with the Sun Workshop C++ compiler when creating a C++ library that requires libm. I obs

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney wrote: > > I think I have discovered a bug in libtool's link behavior with the > Sun Workshop C++ compiler when creating a C++ library that requires libm. > I observed it on x86_64-sun-solaris2.10, but it may also affect

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

On Thu, 20 Mar 2008, Tim Mooney wrote: Perhaps it is not best to run most of your configure script using the C++ compiler. Only run the C++ compiler to test C++ things. I don't disagree, but at the same time, if everything a project is going to build is going to be compiled by the C++ compil

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...: On Wed, 19 Mar 2008, Tim Mooney wrote: That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect

Re: libtool C++ link bug with -lm functions with Sun Workshop compiler

On Wed, 19 Mar 2008, Tim Mooney wrote: That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect sqrt(), because the C++ compiler added `-lm -lc' behind the scenes. Then it seems

libtool C++ link bug with -lm functions with Sun Workshop compiler

I think I have discovered a bug in libtool's link behavior with the Sun Workshop C++ compiler when creating a C++ library that requires libm. I observed it on x86_64-sun-solaris2.10, but it may also affect the Workshop C++ compiler on Linux too. I found it when trying to build GNU aspell 0

Re: libtoolize /ltmain.sh bug

Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part _______ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: GNU Automake 1.10.1 released -- bug #516 is still there

On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Automake is a tool Very good, BUT more than a year ago I filed a bug report (automake#516), after sending an email some month earlier: automake generated Makefiles install manpages

Re: MinGW/Cygwin wrapper bug

On Wed, Dec 05, 2007 at 12:05:39AM +0100, Peter Rosin wrote: > did some extra work to try to force the issue (build m in some other > dir). ...so that m.exe will not pick up the freshly built dll sitting right beside it in the .libs dir, which will happen otherwise (current dir is searched before

Re: MinGW/Cygwin wrapper bug

am > > the only one who has reported the problem. > > OK so here's a try of mine. Can you confirm that this exposes the bug, > i.e., the last line prints 1 instead of 0? > > Or is it rather that you have a problem at link time? Then the last > mode=link should fai

Re: MinGW/Cygwin wrapper bug

On Tue, 4 Dec 2007, Ralf Wildenhues wrote: But I won't write a fix before I get the answer to the question whether the test I just wrote exposes the bug. Answer that please. And include the Libtool version you have used. Thanks. It could be a long wait since I don't know

Re: MinGW/Cygwin wrapper bug

en removed since the > previous install, the user is not likely to immediately (if ever) > notice that the wrong DLL is used for testing. This sort of bug > causes much frustration on the part of developers. OK, thanks, I guess I know now what the failure is. > Since DLLs are installed

Re: MinGW/Cygwin wrapper bug

here's a try of mine. Can you confirm that this exposes the bug, i.e., the last line prints 1 instead of 0? Or is it rather that you have a problem at link time? Then the last mode=link should fail iff, on the line marked XXX, `int a' is replaced with `int b'. Which of the two susp

Re: MinGW/Cygwin wrapper bug

Can you confirm that this exposes the bug, i.e., the last line prints 1 instead of 0? Or is it rather that you have a problem at link time? Then the last mode=link should fail iff, on the line marked XXX, `int a' is replaced with `int b'. Which of the two suspected setups is the

Re: MinGW/Cygwin wrapper bug

On Tue, 4 Dec 2007, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Dec 04, 2007 at 03:24:41AM CET: I notice that the wrapper that libtool builds for MinGW/Cygwin still has a nasty bug in which tests of a shared build will wrongly use an already installed DLL rather than the one just

Re: MinGW/Cygwin wrapper bug

Hi Bob, * Bob Friesenhahn wrote on Tue, Dec 04, 2007 at 03:24:41AM CET: > I notice that the wrapper that libtool builds for MinGW/Cygwin still > has a nasty bug in which tests of a shared build will wrongly use an > already installed DLL rather than the one just built. The system use

MinGW/Cygwin wrapper bug

I notice that the wrapper that libtool builds for MinGW/Cygwin still has a nasty bug in which tests of a shared build will wrongly use an already installed DLL rather than the one just built. The system uses PATH to search for DLLs. Bob == Bob Friesenhahn

Re: bug with dlpreopening c++ modules (shared objects)

Hello Christian, * Christian Keil wrote on Mon, Sep 24, 2007 at 05:14:44PM CEST: > > I might have discovered a bug with regard to dlpreopening when dealing > with c++ modules. > > The attached tar.gz contains a very small project that just tries to > open a module specified o

Re: libtool make check bug

the output of ./libtool --config What's really weird about the above output is that there should be a message about some hardcoding that `fooled libtool'. Was there maybe a | `hc-libpath' was not linked properly, which fooled libtool or similar near the end of the output

Possible bug regarding exeext

Hi! I believe i found a bug regarding exeext in libtool. When generating the tag configuration to the "libtool" script there is a line: exeext="$exeext" Which seems wrong, since nowhere ever $exeext is set. When changing $exeext to $ac_exeext everything works fine, and the

[Bug-spacechart] perpsective business

n in childbirth," Lucilius reported. "Wept. _______ Bug-spacechart mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-spacechart

RE: message to the bug-libtool list

Title: RE: message to the bug-libtool list See in line -Original Message- From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]] Sent: Friday, September 22, 2006 9:34 AM To: Jitesh Jhatakia Cc: bug-libtool@gnu.org Subject: Re: message to the bug-libtool list [ bug-libtool readers: the

Re: message to the bug-libtool list

[ bug-libtool readers: the original bug report was filtered ] Hello Jitesh, * Jitesh Jhatakia wrote on Fri, Sep 22, 2006 at 05:16:12PM CEST: > > Tagdemo-make.test failed 2 times once for tagdemo-conf.test and 2nd time > for tagdemo-shared.test. Thanks for the bug report. Could you pl

[Bug-kawa] 少し遊びましょう

‚ª‚ ‚è‚Ü‚·B Å’áŒÀ‚̃}ƒi[‚ðŽç‚Á‚½ã‚Å‘f“G‚ÈŽžŠÔ‚ð‚Ç‚¤‚¼‚¨‰ß‚²‚µ‰º‚³‚¢B http://www.free-premium.com/sereb/Ps007/ —â‚â‚©‚µAˆ«‹Y–Ú“I‚Ì‚¨‹q—l‚Í”rœ‚³‚¹‚Ä’¸‚¢‚Ä‚¨‚è‚Ü‚·B 632811977332349736 ___ Bug-kawa mailing list [EMAIL PROTECTED] http

Re: Recheck Bug??

Hello Markus, A while ago you wrote: * Duft Markus wrote on Thu, Jul 20, 2006 at 08:17:41AM CEST: > > seems i found a little ... äähmm ... bug(??) ;o) when i do: > > $ CC=wgcc CXX=wgcc LD=wgcc ../libtool-1.5.22/configure > --prefix=/wamas/libtool/test/binary > > and

Recheck Bug...

Hi!   Seems i was wrong with the recheck bug. Whenever i reconfigure in a directory where i allready configured libtool i get this:   rm -f ltmain.shTdate=`/bin/sh ../libtool-1.5.22/mkstamp < ../libtool-1.5.22/ChangeLog` &&  sed -e 's/@''PACKAGE@/libtool/' -e

Recheck Bug??

Hi together!   seems i found a little ... äähmm ... bug(??) ;o) when i do:   $ CC=wgcc CXX=wgcc LD=wgcc ../libtool-1.5.22/configure --prefix=/wamas/libtool/test/binary   and after that bootstrap libtool, and do "$ gmake" libtool trys to recheck with:   $ gmake/bin/sh ./con

Bug in documentation about how to update -version-info?

I sent the below to [EMAIL PROTECTED], but it's been a month with no response, so now I'm trying [EMAIL PROTECTED] instead: Max Bowsher wrote: > Looking at the documentation about how to update -version-info: > > 1. Start with version information of `0:0:0' for each libtool library. > > 2. U

Re: BUG (cygwin 1.5.19-4): libdl.a is missing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 6/4/2006 5:38 PM: > > I've added a libdl.a to the latest snapshot, however any project which > relies on the existence of this library without checking to see if it > exists is broken as far as portability is concern

Bug

I am a new Linux User. And it gives me this error and told me to report the bug. I feel it might helpful if the problem is real other than my mistake in making the files.Meron[EMAIL PROTECTED] libtool-1.5.22]# ./configurechecking for a BSD-compatible install... /usr/bin/install -cchecking whether

Re: Bug with linker flags under cygwin?

Hi Christopher, * Christopher Hulbert wrote on Fri, Feb 10, 2006 at 09:29:44PM CET: > I'm trying to pass some options to the linker using -Wl,opt1,opt2, > Libtool is not placing the -Wl, in front of each argument because in > the generated libtool script, wl="". If I manually replace that w

Bug with linker flags under cygwin?

I'm trying to pass some options to the linker using -Wl,opt1,opt2, Libtool is not placing the -Wl, in front of each argument because in the generated libtool script, wl="". If I manually replace that with wl="-Wl," it prepends arguments with it as expected. bash-3.00$ uname -a CYGWIN_NT-5.1

Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)

g_spec=' ' (a single space), thereby activating a > > wrong branch of the convenience library code in libtool. > > After having modified this setting to whole_archive_flag_spec= > > (empty), thereby suppressing linker-automated whole-archive > > processing on AIX5, cou

Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)

Peter Yes, setting whole_archive_flag_spec='$convenience' fixes the bug. Best regards - Jorgen - Original Message - From: "Peter O'Gorman" <[EMAIL PROTECTED]> To: "Jørgen Moth" <[EMAIL PROTECTED]> Cc: "Libtool" ; "Allan Duka

Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)

nch-1-5 it is ' ', and in HEAD '$convenience', would seem like '$convenience' might be correct. Can you check, please, if setting whole_archive_flag_spec='$convenience' also fixes your bug? Thanks, Peter -BEGIN PGP SIGNATURE- Version: G

Re: AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)

pec= > (empty), thereby suppressing linker-automated whole-archive > processing on AIX5, courier-authlib installs smoothly! Thank you for this bug report. In fact, we have fixed this behavior in the CVS HEAD version of Libtool (along with a couple more changes for AIX), but not ported the patch ba

AIX5.x bug in libtool as generated by configure script used by courier-authlib-0.57)

: Jørgen Moth To: Courier Users Cc: Allan Dukat Sent: Wednesday, November 16, 2005 11:57 AM Subject: [courier-users] bug in configure script for courier-authlib-0.57 Hi We have been strugling without success for a long time now to install the new separated courier-authlib on IBM AIX 5.x to allow us

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

\2/p' | /usr/bin/sed 's/.* //' | sort | uniq > .libs/libfoo2.exp libtool: link: /usr/bin/grep -E -e "libfoo2.*" ".libs/libfoo2.exp" > ".libs/libfoo2.expT" libtool: link: mv -f ".libs/libfoo2.expT" ".lib

Re: Bug in the doc?

Hi Jan, * Jan Engelhardt wrote on Wed, Sep 28, 2005 at 01:56:17PM CEST: > > the info pages for libtool says > > " Shared libraries, however, may only be built from > "position-independent code" (PIC). So, special flags must be passed to > the compiler to tell it to generate PIC rather than th

Re: Bug in the doc?

On Wednesday 28 September 2005 07:56 am, Jan Engelhardt wrote: > " Shared libraries, however, may only be built from > "position-independent code" (PIC). So, special flags must be passed to > the compiler to tell it to generate PIC rather than the standard > position-dependent code." [libtool.in

Bug in the doc?

Hi, the info pages for libtool says " Shared libraries, however, may only be built from "position-independent code" (PIC). So, special flags must be passed to the compiler to tell it to generate PIC rather than the standard position-dependent code." [libtool.info.gz] This looks wrong to me.

FYI: ksh bug on Tru64 UNIX causes current libtool failure

This is the ancient bug report about the Tru64 shell. * Nicolas Joly wrote on Tue, Jun 07, 2005 at 12:10:47PM CEST: > > In the mean time, i tested the solution where `print -r' and `ksh' > tests are swapped (attached patch). It seems to go a little further > (no more `print

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes: [...] Bruno> all-local $(libfoo_la_OBJECTS): $(ARGZ_H) Hmmm, why do you need this since $(ARGZ_H) is already in $(BUILT_SOURCES), and "all" depends on $(BUILT_SOURCES)? -- Alexandre Duret-Lutz __

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

Hi Bruno, * Bruno Haible wrote on Mon, Jul 11, 2005 at 01:23:26PM CEST: > > The modules in gnulib are normally used in a directory that creates a > single library, say libfoo.la, and in this case a line like > > all-local $(lib_OBJECTS): $(ARGZ_H) > > is meant to be changed to > > all-loca

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

stored in > libltdl/.deps/*.Plo, and thus hides this bug. > > Now the gnulib snippet in libltdl/Makefile.am leaves us with the > possibility of using the lib_OBJECTS variable to fix this(?). > > Several questions (thus the crosspost to all of these lists): > - Is it ok/supposed b

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

On Sun, Jul 10, 2005 at 11:34:13AM +0900, Peter O'Gorman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Albert Chin wrote: > > |>05:00 PM dogbert ~$PS1='$ ' /bin/sh > |>$ echo Xbla | sed 1s,^X,, > |>X,,: not found > |>$ sed: Function 1s, cannot be parsed. > | > | > | What system is

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Chin wrote: |>05:00 PM dogbert ~$PS1='$ ' /bin/sh |>$ echo Xbla | sed 1s,^X,, |>X,,: not found |>$ sed: Function 1s, cannot be parsed. | | | What system is this? Works fine on 4.0D and 5.1. | I don't think you tried /bin/sh. Works okay with z

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

On Thu, Jul 07, 2005 at 05:02:26PM -0500, Tim Mooney wrote: > In regard to: Re: FYI: ksh bug on Tru64 UNIX causes current libtool...: > > >* Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: > >> > >>This is a gentle reminder that this issue with Libtoo

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

In regard to: Re: FYI: ksh bug on Tru64 UNIX causes current libtool...: * Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: This is a gentle reminder that this issue with Libtool HEAD/branch-2-0 on Tru64 sh is still unsolved. It'd be nice to get a solution into the nex

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

* Ralf Wildenhues wrote on Wed, Jul 06, 2005 at 05:08:11AM CEST: > > This is a gentle reminder that this issue with Libtool HEAD/branch-2-0 > on Tru64 sh is still unsolved. It'd be nice to get a solution into the > next 2.0 release candidate, should such a solution exist. Stupid question: Does

Re: FYI: ksh bug on Tru64 UNIX causes current libtool failure

t; > > > > > > > > > In the mean time, i tested the solution where `print -r' and `ksh' > > > > > tests are swapped (attached patch). It seems to go a little further > > > > > (no more `print' error messages), but seems to fail i

  1   2   3   >