[Top][All Lists]
[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.