libtool-patches
[Top][All Lists]
Advanced

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

Re: Don't export lt__error_strings (was: Libtool stresstest.at segfault


From: Ralf Wildenhues
Subject: Re: Don't export lt__error_strings (was: Libtool stresstest.at segfault on Cygwin/MinGW)
Date: Fri, 23 Sep 2005 15:36:30 +0200
User-agent: Mutt/1.4.1i

Hi Peter,

* Peter Ekberg wrote on Fri, Sep 23, 2005 at 02:02:18PM CEST:
> * Ralf Wildenhues [mailto:address@hidden 
> > * Peter Ekberg wrote on Thu, Sep 22, 2005 at 04:05:54PM CEST:
> > > 
> > > Are there other platforms with data export difficulties?
> > 
> > Not that I know of.  Don't the w32-related ones give you enough
> > headaches already?  ;-)
> 
> Right :-) But for a change it would be nice if w32 were not the
> only oddball system. Just curious.

AIX is pretty oddball, but I don't believe especially w.r.t. data
exports.

> > Data exports are trickier than one thinks.  For example, the 
> > size of an exported array is part of the interface.  :-/
> > 
> > Erm, now that I mention it: if someone would change
> > lt__error_strings to be used through an accessor function, that
> > would be *great* (it was not part of 1.5 interface).
> 
> I see that lt__last_error is also exported. Further, I don't
> see any record of this being published interfaces, so the
> only thing that matters is that the loaders get it right,
> right?

Right.

> So, here's a patch:

Major nit: it doesn't compile:

| +const char *
| +lt__set_last_error_string (const char *errormsg)
| +{
| +  return lt__last_error = last_error;
|  }

You wanted to set it to errormsg, not last_error.

Minor nit: I would have liked the issue to be solved _right_, i.e.,
without any remaining necessary relocations.  Might as well show users
how to achieve this with an array of strings.  Do you want work on this?

If yes, please read dsohowto.pdf chapter 2.4.3 (or around there) titled
"Arrays of Data Pointers" and Appendix B.  I would probably prefer
the first described method (should be the least work, too), but we
might need to adapt it a bit so all compilers grok it, i.e., do:

  static const char msgs[LT_ERROR_MAX][LT_ERROR_LEN_MAX + 1] = {
    "msg1",
    ...
  };

instead of using C99 designated initializers

  static const char msgs[LT_ERROR_MAX][LT_ERROR_LEN_MAX + 1] = {
    [ERR1] = "msg1",
    ...
  };

but you might want to look at the other proposed methods, too.

>       * libltdl/libltdl/lt__private.h, libltdl/lt_error.c:
>       Don't export the lt__last_error and lt__error_strings
>       variables.
>       * libltdl/libltdl/lt__private.h (LT__STRERROR, LT__GETERROR)
>       (LT__SETERRORSTR): Adjust to not use the above variables,
>       instead use the following functions...
>       * libltdl/lt_error.c: (lt__error_string, lt__last_error_string)
>       (lt__set_last_error_string): Reimplement the functionallity
>       in these functions instead.
>       * libltdl/m4/ltdl.m4: Bump serial number.
> 
> The serial number bump in libltdl/m4/ltdl.m4 is just a guess...

It's wrong.  macro serial version and library interface version are
independent of one another.  If at all, Makefile.am:VERSION_INFO should
be changed.  But we agreed not to do that (I only haven't updated
HACKING yet).

Cheers,
Ralf




reply via email to

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