libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libtool head: stresstest.at export of w8$ symbol


From: Ralf Wildenhues
Subject: Re: Libtool head: stresstest.at export of w8$ symbol
Date: Thu, 8 Sep 2005 09:41:47 +0200
User-agent: Mutt/1.4.1i

Hi Peter,

Finally I've managed to do another round of testing on mingw/cygwin..
Sorry for the delay.

* Peter Ekberg wrote on Fri, Sep 02, 2005 at 09:50:01PM CEST:
> Ralf Wildenhues wrote:
> > * Peter Ekberg wrote on Fri, Sep 02, 2005 at 12:03:14PM CEST:
> > > 
> > > I'm trying to make sence of the problem with stresstest.at on
> > > Windows (MinGW, Cygwin and MSVC) where the following symbols
> > > can't be exported during linking of dlself with -export-symbols
> > > dlselfsyms:
*snip*

> Heh, I searched back in the cvs archives looking for clues,
> and think the first line of the sed program have been warped
> in some cleanup...
> 
> What's there currently is this (minus m4 quotes):
> 
> -e 's/\([ ][.*^$]\)/\\\1/g'
> 
> Originally it was:
> 
> -e 's/\([][.*^$]\)/\\\1/g'
> 
> Which makes much more sense, it's just a general escape for
> the later grep, to not have any surprises. (if the symfile is
> constructed badly or something, I don't really see the need
> here, but that's irrelevant...)

OK, I remember now why I changed that (but my change was wrong, of
course):
  s/\([][.*^$]\)/\\\1/g
is a sed syntax error.  This is because `[.' in a bracket expression
starts a character class, so sed expects a `.]' to finish that
eventually.  Instead, this
  s/\([].[*^$]\)/\\\1/g
should work.  This error does show up under cygwin and mingw stresstest
(both with gcc):
| /usr/bin/sed: -e expression #1, char 20: unterminated `s' command

Looking back, it now makes sense why the original authors did not
encounter this error: most likely, the sed of seven years ago did
not know about character classes and parsed this just fine.

However, with that change, stresstest still eventually fails with a
| Cannot export w1$: symbol not defined
| Cannot export w10$: symbol not defined
| ...

on mingw, and a

| grep: Invalid back reference
| /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: 
sub3/.libs/dlself.def:8: syntax error
| 
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:sub3/.libs/dlself.def:
 file format not recognized; treating as linker script
| 
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:sub3/.libs/dlself.def:2:
 syntax error
| collect2: ld returned 1 exit status

on cygwin, both with gcc.  (Yes, I should be implementing better
stresstest error reporting first..)

> Now I just need someone to explain why the w8 symbol has a
> $ suffix in the symfile. There is definitely something fishy
> here, as the $ is passed on from the symfile to the grep
> command, which doesn't seem like the intended design...
> 
> So, one of these cases are right:

> 3. the $ has no meaning to any tool and the $ in w8$ in
>    the test is to be zapped and the symbols in the symfile
>    are supposed to be escaped as a precaution before being
>    used as grep patterns

This one is mostly right, I believe: the `$' does not belong there.

The only thing I could not find out yet is:
- whether on some systems the symbol file has been used/is in use with
  wild cards or some kind of regular expressions which either the
  ltmain script or the linker understands,  
- or some "active" characters (like `$', `[') need to be specifyable
  as part of symbol names because some systems use these for mangling
  and/or versioning.

Strictly speaking, we are safe to kill the first possibility, as it is
not mentioned in the documentation, and surely it is not portable as of
now; but is not explicitly forbidden either, so I only want to step on
toes if I have to.

(By the way, similarly to -export-symbols-regex, we _could_ add a new
interface to libtool with symbol files which allow regexes/wildcards..
something for the TODO list after 3.x :)

> I'm putting my money on 3, so here's a patch that fixes the
> escape, but not the test. Ok to commit?

Not exactly like this, see above.  And if possible, I'd like to
eliminate the remaining failure.  :)

Cheers,
Ralf

>       * libltdl/config/ltmain.m4sh (func_generate_dlsyms):
>       Fix escape expression to actually escape relevant
>       characters from the following grep.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]