Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Fri, Sep 24, 2010 at 11:30:07AM CEST:
> Den 2010-09-24 06:20 skrev Ralf Wildenhues:
> > The part about this patch which I'm unsure about is this:
> > 
> > Does the testsuite otherwise cover well enough the fact that users may
> > name their modules with or without leading 'lib' prefix (and with .la or
> > .dll or .so suffix or so)?
> > 
> > IOW, I'd like to be sure we're not hiding anything here.
> 
> But that is not a problem with *this* patch.  That's one of those gigantic
> tasks that Chuck mentions from time to time.
> 
> This is not like the low max_cmd_len test.  In both cases the libtool
> script is rigged to simulate weird conditions, but the need_lib_prefix
> test is rigging something that never happens on platforms that never
> create a lib prefix.  You should also not confuse this prefix with the
> name of the .la file, the .la files are always allowed to have a lib
> prefix, this is about the real libraries.

Ah, ok.

> We have plenty of tests that create -modules named module.la without the
> prefix, for example dlloader-api.la.  I'm not sure what you mean by users
> naming their modules with various suffixes, as they must be named .la?

No, they don't.  On GNU/Linux, you ought to be able to, say,
  lt_dlopen("foo.so", ...)

if you like.  There are users of libltdl that do this.  Of course, that
requires the users to be aware of the system-specific naming issues, but
ideally, some way like this should work on other systems, too.

> I get the feeling that I'm saying things that you already know, so I'm
> probably missing something.  What?

I don't think you are, apart from the above.

> > And yes, I think (part of) the log entry from the initial test addition
> > probably deserves to be a comment in the test, so we don't have to look
> > it up again.
> 
> Probably a good idea.  I'll add some words before pushing anything, but
> I'd like this settled before doing anything further with the patch.

In light of your response, and if my response above doesn't invalidate
your reasoning, the patch is ok with me, with that comment added.

Thanks,
Ralf