Re: ./bootstrap --help
> +$0: This is libtool bootstrap, designed to bootstrap a fresh CVS > + checkout. Run with reconfdirs=. in the environment to speed up bootstrap, > + at the expense of not configuring the testsuite. Run with > + WORKING_LIBOBJ_SUPPORT=: in the environment if you have a fixed autoconf > + (> 2.59) and automake (> 2.9.6). > +EOF hmm... I thought automake 1.9.6 is the latest version. Did I miss something? -- Greetings, Christoph Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Re: workaround for virtualpc bug
> > Cannot export : symbol not defined > > Creating library file: $output_objdir/$libname.dll.a > > collect2: ld returned 1 exit status > > Could you try using a patched sed that prints the argument to > compile_program (e.g. on stderr)? well yes, if I get the patched sed... > > Paolo > -- Greetings, Christoph 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++
Re: SCO/bugfix patch 10 of 10: --version-info improvement
> Patch 10 of 10 attached ... > > Rationale: > > I expect a lot of resistance to this patch :) Let me just start of by > saying that I already know most of the objections why you dont want to > explicitly name a shared library. However, it is a very useful option > and I hope to explain why. > > I have encountered at least two applications so far that do a realpath() > on a shared library, and then check the SONAME to ensure that they match > a compile-time constant. I know, the applications are retarded. But > libtool is a program that is supposed to make creating shared libraries > easier, and having the ability to actually have control over things like > the SONAME make it more generically useful, and caters for situations > that we may not have forseen. The current scheme uses soname_spec as the > sole mechanism for setting the SONAME for a shared library. This is > a calculated name based on the current library version. However, as > a programmer, I may know that even though shared library version Y > has some incompatible interfaces relative to version X, that those > chages are a pure superset of X. Thus, I want the new version Y to > also be available to old programs that linked against version X. The way > you would *want* to do this is with a simple symlink during packaging. > 99.999% of the time, that will suffice. Only really stupid applications > that do crap like realpath() and checking the SONAME will fail. Its a > tiny corner case, but this patch provides a mechanism for covering it. > I can't really see a downside to this, to be honest. > > 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> > >* ltmain.in: Provide a mechanism for explicitly setting the value >of SONAME in a shared library using an optional 4th argument to >--version-info. > > * doc/libtool.texi: Document it. I don't expect this patch to get accepted because there's already a patch from Keith Packard which addresses this issue: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html -- Greetings, Christoph 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++
Re: workaround for virtualpc bug
> Hi Christoph, > > * Christoph Egger wrote on Sat, Oct 29, 2005 at 01:20:00AM CEST: > > > > > > Could you please find out for me: > > > - whether empty files in general get messed up in your setup > > > - whether newline encoding is the issue > > > - whether the > > >sed -e '/[ ,]DATA/!d;s,\(.*\)\([ \,].*\),s|^\1$|\1\2|,' > > > outputs something weird. > > > > I created a small script, which tests all these cases. > > If it is really a sed bug, then it should reproduce the issue. > > So, does it reproduce the issue now? :) > Can you see which part is at fault? Aaargh! What happened with my mail? The one I sent was MUCH longer! No, it did NOT reproduce any error of them. All tests were successful. Independent if Virtual PC runs in foreground or background. I downloaded the source of GNU sed 4.1.4 and looked into it. sed uses fopen(), fread() and fclose() to handle the -f option. It uses a subroutine called 'compile_program()', which sed also uses to parse the commands passed with -e. And we know -e works, so the bug can't be there. The question is why does cp not fail? I mean, why does my libtool patch work? So I downloaded the source of GNU fileutils and looked into cp's code. It uses open(), read(), write() and close(). The difference: fopen(), fread(), fwrite() and fclose() use a FILE *. This uses libc's internal cache buffer. open(), read(), write() and close() use filedescriptors and bypass libc's caching. I also checked libtool and libtool uses sed with the -f option only one time in the whole source. So this should actually be the only one impacting place. It doesn't look like to be a bug in sed. And I pretty doubt that libc's caching is that buggy to garbarge it's memory. Such a bug should be found and fixed pretty fast, since really MANY programs use fopen(), fread(), etc. So when it is a bug in Virtual PC, why does my above script not fail? Actually I don't know. And because VirtualPC is closed-source I can only make a guess: The above script is not complex enough (as libtool is) and/or does not "the right thing" to expose the bug in VirtualPC which garbages libc's cache used when sed is called with -f _later_. For more detailed analyzes send me the source of VirtualPC... :-) -- Greetings, Christoph Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Re: workaround for virtualpc bug
> Hi Christoph, > > * Christoph Egger wrote on Fri, Oct 28, 2005 at 09:56:09PM CEST: > > > * Christoph Egger wrote on Fri, Oct 28, 2005 at 03:00:21PM CEST: > > > > > > > > When the conditions are met and the error appears, then you see > > > > this error: > > > > > > > > Cannot export : symbol not defined > > > > Creating library file: $output_objdir/$libname.dll.a > > > > collect2: ld returned 1 exit status *snip* > > > > The patch works around the bug in virtualpc by not operating > > > > on an empty file. > > > > > > Wouldn't this rather be a bug in sed? > > > > If this is a bug in sed, why wouldn't it have been catched earlier? > > Hey, I don't know. Apparently it isn't. > > > I mean, if it is a sed bug rather one in virtualpc, then there > > should be more platforms where this issue is reproducable. > > > > > > The patch has been reviewed and okey'd by Peter Ekberg (who > > > > originally wrote the piece of code the patch touches). > > > > > > Does this simpler patch also work? > > > > No, this patch does not work. hmm... so my patch is more likely > > to work around a bug in sed than in virtualpc then ...? > > Likely. Maybe not. See below. > > > Which sed version is this, by the way? > > > > This is GNU sed 4.1.4. > > OK. I would like to understand the issue before applying your patch: > I dislike very much any 'fix' where the issue isn't fully analyzed, for > several reasons: there might be other places that need fixing, the issue > might be solved easier or more thoroughly in a different way, some other > component might need fixing instead of Libtool (or additionally). > > Could you please find out for me: > - whether empty files in general get messed up in your setup > - whether newline encoding is the issue > - whether the >sed -e '/[ ,]DATA/!d;s,\(.*\)\([ \,].*\),s|^\1$|\1\2|,' > outputs something weird. I created a small script, which tests all these cases. If it is really a sed bug, then it should reproduce the issue. -- #!/bin/sh SED="/usr/bin/sed" # Use file mapped from MacOSX into VirtualPC orig_export_symbols="/cygdrive/z/ggi/ggi-core/libgii/input/null/EXPSYMS" # Steal .libs/null.exp from building error. This safes me to copy # tons of libtool code into here... $SED -e '/[ ,]DATA/!d;s,\(.*\)\([ ,].*\),s|^\1$|\1\2|,' < .libs/null.exp > null.filter # This is the (failing) command in question $SED -f null.filter < $orig_export_symbols > null.def # octal dump output to see if content is garbaged which # would be the reproduced error od -a null.def -- Greetings, Christoph Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Re: workaround for virtualpc bug
> Hi Christoph, > > * Christoph Egger wrote on Fri, Oct 28, 2005 at 03:00:21PM CEST: > > > > The following condition must be met to reproduce the virtualpc bug: > > > > - VirtualPC must run in the background or in the dock > > - you must link a module and use -export-symbols > > - $output_objdir/$libname.filter must be empty > > Wow. yeah... > > When the conditions are met and the error appears, then you see > > this error: > > > > Cannot export : symbol not defined > > Creating library file: $output_objdir/$libname.dll.a > > collect2: ld returned 1 exit status *snip* > > The patch works around the bug in virtualpc by not operating > > on an empty file. > > Wouldn't this rather be a bug in sed? If this is a bug in sed, why wouldn't it have been catched earlier? I mean, if it is a sed bug rather one in virtualpc, then there should be more platforms where this issue is reproducable. > > The patch has been reviewed and okey'd by Peter Ekberg (who > > originally wrote the piece of code the patch touches). > > Does this simpler patch also work? No, this patch does not work. hmm... so my patch is more likely to work around a bug in sed than in virtualpc then ...? > Which sed version is this, by the way? This is GNU sed 4.1.4. > Cheers, > Ralf -- Greetings, Christoph Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
workaround for virtualpc bug
Hi! I've attached a patch which works around a bug in VirtualPC. (Sorry for using application/octet-stream, but the webmail interface provides no way to choose text-type) I spent lots of time to track down what goes wrong and under which conditions. I have the following environment: - Windows 2000 runs in Virtual PC. - Virtual PC runs under MacOSX Tiger - In Virtual PC the VPC-Addons for Windows are installed - In Windows 2000 runs cygwin. - The source tree is mapped into VirtualPC, windows see's it as an extra drive The following condition must be met to reproduce the virtualpc bug: - VirtualPC must run in the background or in the dock - you must link a module and use -export-symbols - $output_objdir/$libname.filter must be empty When the conditions are met and the error appears, then you see this error: Cannot export : symbol not defined Creating library file: $output_objdir/$libname.dll.a collect2: ld returned 1 exit status then when you run on the console: od -a $output_objdir/$libname.def then you get this: 000 nul nul nul 003 or sometimes this: 000 ` / soh 003 The patch works around the bug in virtualpc by not operating on an empty file. The patch has been reviewed and okey'd by Peter Ekberg (who originally wrote the piece of code the patch touches). Enjoy! -- Greetings, Christoph Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl ltmain-virtualpc.m4sh.diff Description: Binary data
Re: darwin: mix up of .dylib and .bundle
> [ taking out bug-libtool ] > > Hi Christoph, Peter, > > * Christoph Egger wrote on Sun, Oct 16, 2005 at 07:58:39PM CEST: > > > Christoph Egger wrote: > > > > > > > file -L /path/to/with/ggbundle/in/it | grep bundle will return true! > > > > > > Let me look into a patch, probably testing for 'Mach-O bundle' is > > > better than testing for 'bundle'. > > > > I've attached a patch, which fixes this bug. > > I also added comments (two lines) which explains what it does and why. > > libtool no longer needs to worry about any directory names. > > A couple of random thoughts: > > With the sed in place, should not grepping for `bundle' suffice? > > A casual glance at my "magic" file suggests the possibility of > `Mach-O ' > `Mach-O fat file ' > `Macintosh MacBinary data ' (commented out) > > before the `bundle'. This might be completely unrealistic, but I don't > know darwin at all, so darwin experts please decide. :) > > Also, can't we eliminate the extra process? How about a grep for > `: [^:]* bundle' instead, given above? (Watch out, ltmain.m4sh needs > the brackets m4-quoted!) I tried this and it works, too. Patch attached. Please review and decide whether to apply this or the previous version :) -- Greetings, Christoph Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl ltmain.m4sh.diff Description: Binary data
Re: darwin: mix up of .dylib and .bundle
> Christoph Egger wrote: > > > > Attached. > > libgii-debug-experimental.output.gz is the whole subdirectory > > as I sent in my last mail with debug info. > > libgii-debug-experimental.output2.gz is the failing libtool link > > line with debug info. > > Doh! In a directory named ggbundle, > file -L /path/to/with/ggbundle/in/it | grep bundle will return true! > > Let me look into a patch, probably testing for 'Mach-O bundle' is better > than testing for 'bundle'. I've attached a patch, which fixes this bug. I also added comments (two lines) which explains what it does and why. libtool no longer needs to worry about any directory names. Please review and apply. -- Greetings, Christoph Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ltmain.m4sh.diff Description: Binary data
darwin: mix up of .dylib and .bundle
Hi! libtool mixes up .dylib and .bundle. It thinks, .dylib are modules and .bundle are shared libs. This causes linking failures on darwin due to multiple defined symbols, in cases where libfoo.dylib is inherited from libbar.dylib and the program foo links against libbar.dylib and libfoo.dylib. libtool also prints a warning, "libfoo.dylib is a module, not a shared library", which is wrong. I've attached a patch against cvs head which fixes this (for me at least). If the patch is not correct, then please give me one to test. -- Greetings, Christoph Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ltmain.m4sh.diff Description: Binary data
HEAD: fix memory leak on cygwin/mingw
Hi! The attached patch touches libltdl/config/ltmain.m4sh The program_name is a const char * per declaration. base_name() returns a const char *. There's no need make a duplicate. The duplicate just causes an unnecessary memory leak. -- Greetings, Christoph Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ltmain.m4sh.diff Description: Binary data
HEAD: bootstrap failure
Hi! I get an bootstrap failure because of no rule to make target m4/argz.m4, needed in 'Makefile.in'. Stop. The attached patch touches the toplevel Makefile.am and fixes the bug. Then bootstrapping works for me (tm). -- Greetings, Christoph 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ Makefile.am.diff Description: Binary data
Re: inherited linker flags misses linker flags on darwin
> * Christoph Egger wrote on Wed, Aug 24, 2005 at 08:08:39AM CEST: > > Peter wrote: > > > Ralf Wildenhues wrote: > > > > > > > Committed to HEAD. I take it that I no longer need to commit to > > > branch-2-0? > > > > I found this bug in branch-2-0, so the fix belongs to there, too. > > See the recent discussion on the libtool list for the reason of this > question. Yes, but as long as there is no final decision put in stone, I think branch-2-0 should be maintained as before. > > And in the patch you committed to HEAD there's still one bug. > > Look in the for-loop: > > > > *) new_inherited_linker_flags="$new_inherited_linker_flags > > $tmp_inherited_linker_flag";; > > > > Remove this 's'. (Remember to have said this already three times) > > And saying it another time does not make it more right than before. > There is no variable $new_inherited_linker_flag used in ltmain, only > $new_inherited_linker_flags. > > Or have we just been misunderstanding you completely the whole time? hmm.. no, I made a closer look again. When I tested the first version from this patch (the one before Peter went to holiday), I noticed there was something wrong. I read the sh code wrong and thus "fixed" it wrong. Because the build of my sources succeeded I reported "success". Then I read your notice about the missing $ and thought you found another bug... I just retested the final patch that went in and works. -- Greetings, Christoph GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
Re: inherited linker flags misses linker flags on darwin
> Ralf Wildenhues wrote: > > > >>/me kicks self in butt repeatedly. > >> > >>Okay with this fix? > > > > > > Yes, if it passes `make check' with CVS HEAD on darwin, it's fine with > me. > > Committed to HEAD. I take it that I no longer need to commit to > branch-2-0? I found this bug in branch-2-0, so the fix belongs to there, too. And in the patch you committed to HEAD there's still one bug. Look in the for-loop: *) new_inherited_linker_flags="$new_inherited_linker_flags $tmp_inherited_linker_flag";; ^ Remove this 's'. (Remember to have said this already three times) -- Greetings, Christoph 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
Re: inherited linker flags misses linker flags on darwin
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ralf Wildenhues wrote: > > | I backed out this patch. It was obviously broken, and I need at least > | a bit of time to investigate (and do not want bogus bug reports > | because of this patch causing havoc on !darwin). For one, a `$' was > | missing (wonder how I could overlook this on first inspection ;-), > | for another on !darwin it does not work but harms. > > My fault. Shouldn't try to pack and patch at the same time. Hi Peter! Welcome back from vacation. > I believe this is better. There is still one bug remaining in the for loop below. 2005-08-22 Peter O'Gorman <[EMAIL PROTECTED]> * config/ltmain.m4sh (inherited_linker_flags): Work when output is an application too. Reported by Christopher Egger <[EMAIL PROTECTED]> Index: config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v retrieving revision 1.84 diff -u -3 -p -u -r1.84 ltmain.m4sh --- config/ltmain.m4sh12 Aug 2005 21:06:13 -1.84 +++ config/ltmain.m4sh22 Aug 2005 13:47:56 - @@ -3357,19 +3357,20 @@ func_mode_link () # Read the .la file func_source "$lib" -case $host in -*-*-darwin*) - # Convert "-framework foo" to "foo.ltframework" - if test -n "$inherited_linker_flags"; then -tmp_inherited_linker_flags=`$ECHO "X$inherited_linker_flags" | $Xsed -e 's/-framework \([[^ $]]*\)/\1.ltframework/g'` -new_inherited_linker_flags="$new_inherited_linker_flags $tmp_inherited_linker_flags" - fi - dependency_libs=`$ECHO "X $dependency_libs" | $Xsed -e 's% \([[^ $]]*\).ltframework% -framework \1%g'` - ;; -esac +# Convert "-framework foo" to "foo.ltframework" +if test -n "$inherited_linker_flags"; then + tmp_inherited_linker_flags=`$ECHO "X$inherited_linker_flags" | $Xsed -e 's/-framework \([[^ $]]*\)/\1.ltframework/g'` + for tmp_inherited_linker_flag in $tmp_inherited_linker_flags; do +case " $new_inherited_linker_flags " in + *" tmp_inherited_linker_flag "*) ;; + *) new_inherited_linker_flags="$new_inherited_linker_flags $tmp_inherited_linker_flag";; Replace this with (note the change to the singular): *) new_inherited_linker_flags="$new_inherited_linker_flag $tmp_inherited_linker_flag";; +esac + done +fi +dependency_libs=`$ECHO "X $dependency_libs" | $Xsed -e 's% \([[^ $]]*\).ltframework% -framework \1%g'` if test "$linkmode,$pass" = "prog,link"; then - compile_deplibs="$inherited_linker_flags $compile_deplibs" - finalize_deplibs="$inherited_linker_flags $finalize_deplibs" + compile_deplibs="$new_inherited_linker_flags $compile_deplibs" + finalize_deplibs="$new_inherited_linker_flags $finalize_deplibs" else compiler_flags="$compiler_flags $inherited_linker_flags" fi -- Greetings, Christoph 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
Re: inherited linker flags misses linker flags on darwin
> --- Ursprüngliche Nachricht --- > Von: Ralf Wildenhues <[EMAIL PROTECTED]> > An: Christoph Egger <[EMAIL PROTECTED]>, libtool-patches@gnu.org > Betreff: Re: inherited linker flags misses linker flags on darwin > Datum: Mon, 8 Aug 2005 14:06:37 +0200 > > * Ralf Wildenhues wrote on Mon, Aug 08, 2005 at 01:53:06PM CEST: > > > > > 2005-08-06 Peter O'Gorman <[EMAIL PROTECTED]> > > > > > > > > > > * config/ltmain.m4sh (inherited_linker_flags): Work when > output > > > > > is an application too. > > > > > Reported by Christopher Egger <[EMAIL PROTECTED]> > > > > > LOL. I have committed the patch named > > > > | 62-peter-duh-test-the-executable-output-too-peter-idiot.patch > > > > > > > > to HEAD and branch-2-0. > > > > Spoke too soon, sorry. This test breaks inherited_flags.at:20 of CVS > > HEAD. Still investigating.. > > I backed out this patch. It was obviously broken, and I need at least a > bit of time to investigate (and do not want bogus bug reports because of > this patch causing havoc on !darwin). For one, a `$' was missing > (wonder how I could overlook this on first inspection ;-), > for another on !darwin it does not work but harms. You did not my mail correctly: You missed this: +*) new_inherited_linker_flags="$new_inherited_linker_flags $tmp_inherited_linker_flags";; use a singular here: *) new_inherited_linker_flags="$new_inherited_linker_flag $tmp_inherited_linker_flags";; + esac When I tested, I tested w/o this additional s, of course. So please try the inherited_flags.at test with this fix once more. -- Greetings, Christoph GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
Re: inherited linker flags misses linker flags on darwin
> * Christoph Egger wrote on Sat, Aug 06, 2005 at 07:12:46PM CEST: > > > > > > If this works for you maybe someone would be kind enough to commit it > > > while I am gone. > > > 2005-08-06 Peter O'Gorman <[EMAIL PROTECTED]> > > > > * config/ltmain.m4sh (inherited_linker_flags): Work when output > > is an application too. > > Reported by Christopher Egger <[EMAIL PROTECTED]> > *snip* > > This patch works! Someone with cvs write access please commit! > > LOL. I have committed the patch named > | 62-peter-duh-test-the-executable-output-too-peter-idiot.patch > > to HEAD and branch-2-0. Thank you very much. > Do I gather correctly that branch-1-5 is not concerned with this, as > framework support is less there? This issue has been found, fixed and tested on branch-2-0 only. I have no clue if this issue is also related to branch-1-5. -- Greetings, Christoph 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++
Re: FYI: [branch-2-0] fix warnings on cygwin
> Hi Christoph,
>
> Sorry for the late response.
>
> * Christoph Egger wrote on Sat, Jul 16, 2005 at 09:35:40AM CEST:
> >
> > I got some warnings when I build a program on cygwin with latest
> > gcc and -Wcast-qual flag:
>
> > libtool: link: creating evtimestamp.exe
> > ./.libs/lt-evtimestamp.c: In function `main':
> > ./.libs/lt-evtimestamp.c:95: warning: assignment discards qualifiers
> from
> > pointer target type
> > ./.libs/lt-evtimestamp.c: In function `basename':
> > ./.libs/lt-evtimestamp.c:148: warning: cast discards qualifiers from
> pointer
> > target type
>
> Thanks for the bug report. I have applied the following, slightly
> different patch to branch-2-0 and HEAD. It changes basename to
> base_name on the grounds that eventual clashes with system prototypes
> are avoided and our base_name is but a crippled version of the standard
> interface anyway.
Thank you for applying the patch.
But why did you drop one line?
base_name() should return const char * and not char *
The cast in the return makes the compiler still believe
to have to do two castings:
1. Cast from const char * to char * => causes warning
2. Cast from char * back to const char * to fit return type
in the definition/declaration
Please replace
return (char *) base;
with
return base;
and the compiler (and I :) is (are) happy.
> Cheers,
> Ralf
>
> 2005-08-04 Christoph Egger <[EMAIL PROTECTED]>
>
> * config/ltmain.m4sh (func_mode_link) : Change
> basename() to base_name() and have it return a pointer to const,
> fix compilation warnings.
>
> Index: config/ltmain.m4sh
> ===
> RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
> retrieving revision 1.76
> diff -u -r1.76 ltmain.m4sh
> --- config/ltmain.m4sh28 Jul 2005 10:23:18 - 1.76
> +++ config/ltmain.m4sh4 Aug 2005 12:03:16 -
> @@ -5807,7 +5807,7 @@
>
> void * xmalloc (size_t num);
> char * xstrdup (const char *string);
> -char * basename (const char *name);
> +const char * base_name (const char *name);
> char * find_executable(const char *wrapper);
> intcheck_executable(const char *path);
> char * strendzap(char *str, const char *pat);
> @@ -5819,14 +5819,14 @@
>char **newargz;
>int i;
>
> - program_name = (char *) xstrdup ((char *) basename (argv[[0]]));
> + program_name = (char *) xstrdup (base_name (argv[[0]]));
>DEBUG("(main) argv[[0]] : %s\n",argv[[0]]);
>DEBUG("(main) program_name : %s\n",program_name);
>newargz = XMALLOC(char *, argc+2);
> EOF
>
> cat >> $cwrappersource < - newargz[[0]] = "$SHELL";
> + newargz[[0]] = (char *) xstrdup("$SHELL");
> EOF
>
> cat >> $cwrappersource <<"EOF"
> @@ -5883,8 +5883,8 @@
> ;
> }
>
> -char *
> -basename (const char *name)
> +const char *
> +base_name (const char *name)
> {
>const char *base;
>
>
--
Greetings,
Christoph
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++
Re: [branch-2-0] fix warnings on cygwin
> You expect libtool to fix your code? :-) Sorry, I don't understand. > I have never heard of evtimestamp.c before. This is _my_ small program I compile with libtool. libtool itself uses a small program you find in config/ltmain.m4sh, which produces the warnings. The patch fixes them. > > Bob > > On Sat, 16 Jul 2005, Christoph Egger wrote: > > > > > Hi! > > > > I got some warnings when I build a program on cygwin with latest > > gcc and -Wcast-qual flag: > > > > > > libtool: link: creating evtimestamp.exe > > ./.libs/lt-evtimestamp.c: In function `main': > > ./.libs/lt-evtimestamp.c:95: warning: assignment discards qualifiers > from > > pointer target type > > ./.libs/lt-evtimestamp.c: In function `basename': > > ./.libs/lt-evtimestamp.c:148: warning: cast discards qualifiers from > pointer > > target type -- Greetings, Christoph GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
[branch-2-0] fix warnings on cygwin
Hi! I got some warnings when I build a program on cygwin with latest gcc and -Wcast-qual flag: libtool: link: creating evtimestamp.exe ./.libs/lt-evtimestamp.c: In function `main': ./.libs/lt-evtimestamp.c:95: warning: assignment discards qualifiers from pointer target type ./.libs/lt-evtimestamp.c: In function `basename': ./.libs/lt-evtimestamp.c:148: warning: cast discards qualifiers from pointer target type -- Greetings, Christoph 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f�r Mail, Message, More +++ ltmain.m4sh.diff Description: Binary data
[PATCH] Quote AC_MSG_* in m4/libtool.m4
Hi! The attached patch quotes the AC_MSG_* lines in m4/libtool.m4 Patch is for branch-2-0 -- Greetings, Christoph Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl libtool.m4.diff Description: Binary data
Re: recent changes in libtool-2-0 branch cause a m4 loop
> Sorry for the self-replies. > > * Ralf Wildenhues wrote on Sun, Jun 12, 2005 at 01:36:43PM CEST: > > > * Christoph Egger wrote on Sun, Jun 12, 2005 at 01:16:32PM CEST: > > > > > > > > Recent changes in the libtool-2-0 branch causes an > > > > infinite m4 loop. > *snip* > > Argh. Now I understand: it works with CVS Autoconf, but it breaks with > > 2.59. D*mn. :( > > Quick hack: define our own (fixed) versions of m4_car and m4_cdr, so we > are independent of the Autoconf version used. > > Does anybody know a better solution? This patch makes libtool branch-2-0 working with autoconf 2.59 again. Can anyone commit it into branch-2-0, please? The branch-2-0 is still broken... > Regards, > Ralf > > Index: m4/ltsugar.m4 > === > RCS file: /cvsroot/libtool/libtool/m4/ltsugar.m4,v > retrieving revision 1.2.2.2 > diff -u -r1.2.2.2 ltsugar.m4 > --- m4/ltsugar.m4 11 Jun 2005 11:12:28 - 1.2.2.2 > +++ m4/ltsugar.m4 12 Jun 2005 11:59:02 - > @@ -32,6 +32,19 @@ > ]) > > > +# lt_car(LIST) > +# lt_cdr(LIST) > +# > +# Manipulate m4 lists. > +# These macros are necessary as long as will still need to support > +# Autoconf-2.59 which quotes differently. > +m4_define([lt_car], [[$1]]) > +m4_define([lt_cdr], > +[m4_if([$#], 0, [m4_fatal([$0: cannot be called without arguments])], > + [$#], 1, [], > + [m4_dquote(m4_shift($@))])]) > + > + > # lt_combine(SEP, PREFIX-LIST, INFIX, SUFFIX1, [SUFFIX2...]) > # -- > # Produce a SEP delimited list of all paired combinations of elements of > @@ -40,8 +53,8 @@ > m4_define([lt_combine], > [m4_if([$2], [], [], > [lt_join(m4_quote(m4_default([$1], [, ])), > - _$0([$1], m4_car($2)[$3], m4_shiftn(3, $@)), > - $0([$1], m4_cdr($2), m4_shiftn(2, $@)))])]) > + _$0([$1], lt_car($2)[$3], m4_shiftn(3, $@)), > + $0([$1], lt_cdr($2), m4_shiftn(2, $@)))])]) > m4_define([_lt_combine], > [m4_if([$3], [], [], > [lt_join(m4_quote(m4_default([$1], [, ])), > -- Greetings, Christoph Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
Re: recent changes in libtool-2-0 branch cause a m4 loop
> Sorry for the self-replies. > > * Ralf Wildenhues wrote on Sun, Jun 12, 2005 at 01:36:43PM CEST: > > > * Christoph Egger wrote on Sun, Jun 12, 2005 at 01:16:32PM CEST: > > > > > > > > Recent changes in the libtool-2-0 branch causes an > > > > infinite m4 loop. > *snip* > > Argh. Now I understand: it works with CVS Autoconf, but it breaks > > with 2.59. D*mn. :( > > Quick hack: define our own (fixed) versions of m4_car and m4_cdr, so we > are independent of the Autoconf version used. > > Does anybody know a better solution? This patch works with autoconf 2.59. > Regards, > Ralf > > Index: m4/ltsugar.m4 > === > RCS file: /cvsroot/libtool/libtool/m4/ltsugar.m4,v > retrieving revision 1.2.2.2 > diff -u -r1.2.2.2 ltsugar.m4 > --- m4/ltsugar.m4 11 Jun 2005 11:12:28 - 1.2.2.2 > +++ m4/ltsugar.m4 12 Jun 2005 11:59:02 - > @@ -32,6 +32,19 @@ > ]) > > > +# lt_car(LIST) > +# lt_cdr(LIST) > +# > +# Manipulate m4 lists. > +# These macros are necessary as long as will still need to support > +# Autoconf-2.59 which quotes differently. > +m4_define([lt_car], [[$1]]) > +m4_define([lt_cdr], > +[m4_if([$#], 0, [m4_fatal([$0: cannot be called without arguments])], > + [$#], 1, [], > + [m4_dquote(m4_shift($@))])]) > + > + > # lt_combine(SEP, PREFIX-LIST, INFIX, SUFFIX1, [SUFFIX2...]) > # -- > # Produce a SEP delimited list of all paired combinations of elements of > @@ -40,8 +53,8 @@ > m4_define([lt_combine], > [m4_if([$2], [], [], > [lt_join(m4_quote(m4_default([$1], [, ])), > - _$0([$1], m4_car($2)[$3], m4_shiftn(3, $@)), > - $0([$1], m4_cdr($2), m4_shiftn(2, $@)))])]) > + _$0([$1], lt_car($2)[$3], m4_shiftn(3, $@)), > + $0([$1], lt_cdr($2), m4_shiftn(2, $@)))])]) > m4_define([_lt_combine], > [m4_if([$3], [], [], > [lt_join(m4_quote(m4_default([$1], [, ])), > -- Greetings, Christoph Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++
Re: recent changes in libtool-2-0 branch cause a m4 loop
> --- Ursprüngliche Nachricht --- > Von: Ralf Wildenhues <[EMAIL PROTECTED]> > An: Christoph Egger <[EMAIL PROTECTED]>, bug-libtool@gnu.org > Kopie: libtool-patches@gnu.org > Betreff: Re: recent changes in libtool-2-0 branch cause a m4 loop > Datum: Sun, 12 Jun 2005 13:36:43 +0200 > > * Ralf Wildenhues wrote on Sun, Jun 12, 2005 at 01:31:53PM CEST: > > * Christoph Egger wrote on Sun, Jun 12, 2005 at 01:16:32PM CEST: > > > > > > Recent changes in the libtool-2-0 branch causes an > > > infinite m4 loop. > > > > The patch I committed yesterday should fix the problem. > > Please report back whether it works for you. > > Argh. Now I understand: it works with CVS Autoconf, but it breaks with > 2.59. D*mn. :( Exactly. > I need someone else to look at this, I don't have time and will be gone > next week. For now, you could use CVS Autoconf to workaround this. I downgraded m4/ltsugar.m4 to the revision prior to your commit. This works fine for me. -- Greetings, Christoph Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
[PATCH] Quote AC_MSGs in libtool.m4
Hi! The attached patch touches m4/libtool.m4 and is against libtool branch-2-0. It quotes AC_MSG_* consistently as done in m4/ltdl.m4. -- Greetings, Christoph Egger 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ libtool.m4.diff Description: Binary data
[patch] bugfix for -pthread linking
Hello! The changes related to: * config/ltmain.m4sh: Add -pthread like flags when linking executables too. Reported by Andreas Schwab <[EMAIL PROTECTED]> are incomplete. I have attached a patch that fixes the remaining issues: a) Linking an executable or library against a library that needs -pthread fails. b) During creating a library that needs -pthread, the -pthread flag does not go into the 'inherited_linker_flags' variable in the .la file. This leads to an linking failure as in a) The patch fixes the issues. ltmain_stable.m4sh.diff - patch against latest branch-2-0 ltmain_head.m4sh.diff- patch against cvs head Greetings Christoph -- Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail ltmain_stable.m4sh.diff Description: Binary data ltmain_head.m4sh.diff Description: Binary data
