RE: Problem with ltdl.h

2000-11-29 Thread Bernard Dautrevaux

> -Original Message-
> From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 28, 2000 11:53 PM
> To: Kevin Atkinson
> Cc: [EMAIL PROTECTED]
> Subject: Re: Problem with ltdl.h
> 
> 
> On Nov 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> 
> > On 28 Nov 2000, Alexandre Oliva wrote:
> >> On Nov 28, 2000, Bernard Dautrevaux 
> <[EMAIL PROTECTED]> wrote:
> >> 
> >> > in C++
> >> >  struct lt_dlhandle
> >> > automatically define a TYPENAME i.e. makes an implicit
> >> >  typedef struct lt_dlhandle lt_dlhandle;
> >> 
> >> However, IIRC, it is valid to have the implicit name overridden by
> >> another definition of the name, which is what the `typedef' does.
> 
> > So are you saying that you are not going to fix it.
> 
> Not really.  I'm just asking for better arguments to make me change my
> mind about it :-)
> 
> > It does NOT appear
> > to be valid C++ code
> 
> I've just managed to compile:
> 
> typedef struct foo foo;
> 
> with g++, version 2.95.2.  So it *is* valid C++.  I don't understand
> why G++ is complaining about it.

YES! this is valid; what's NOT is

typedef struct foo* foo;
  ^___ notice the '*' there.

canopus{SoftWrks}: echo "typedef struct foo* foo;" > tst.cpp
canopus{SoftWrks}: gcc -c tst.cpp
tst.cpp:1: conflicting types for `typedef struct foo * foo'
tst.cpp:1: previous declaration as `struct foo'
canopus{SoftWrks}: 

> 
> If some widely used C++ compiler fails to compile it, for example,
> when ltdl.h is in its standard header-file search path, then we may
> have a good reason to change it.  But first I want to understand the
> problem, so that it can at least be documented.

ALL C++ comilers should choke on this. AND as I say in my previous mail it
is VERY misleading to typedef a pointer to something with the same name as
this something.

Of course, as I've also said earlier, I don't have the latest CVS libtool,
so I take for granted what the initial message said, that is the offending
code is
typedef struct lt_dlhandle *lt_dlhandle;

If there is no '*', all is OK of course.


Bernard


Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
 

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool



RE: Problem with ltdl.h

2000-11-29 Thread Bernard Dautrevaux

Oops, sending my previous mail just trigger our mail server to notify me of
the other mails :-)

Please forgive the unneeded noise.

Bernard

PS: BTW renaming the struct to "struct lt_dlhandle_struct" or seems better
than renaming again the typedef, as lt_dlhandle is conveying the right
semantics (usually a HANDLE is a pointer to a descriptor of where to find
something).


Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
 

> -Original Message-
> From: Bernard Dautrevaux 
> Sent: Wednesday, November 29, 2000 10:39 AM
> To: 'Alexandre Oliva'; Kevin Atkinson
> Cc: [EMAIL PROTECTED]
> Subject: RE: Problem with ltdl.h
> 
> 
> > -Original Message-
> > From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, November 28, 2000 11:53 PM
> > To: Kevin Atkinson
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Problem with ltdl.h
> > 
> > 
> > On Nov 28, 2000, Kevin Atkinson 
> <[EMAIL PROTECTED]> wrote:
> > 
> > > On 28 Nov 2000, Alexandre Oliva wrote:
> > >> On Nov 28, 2000, Bernard Dautrevaux 
> > <[EMAIL PROTECTED]> wrote:
> > >> 
> > >> > in C++
> > >> >struct lt_dlhandle
> > >> > automatically define a TYPENAME i.e. makes an implicit
> > >> >typedef struct lt_dlhandle lt_dlhandle;
> > >> 
> > >> However, IIRC, it is valid to have the implicit name 
> overridden by
> > >> another definition of the name, which is what the `typedef' does.
> > 
> > > So are you saying that you are not going to fix it.
> > 
> > Not really.  I'm just asking for better arguments to make 
> me change my
> > mind about it :-)
> > 
> > > It does NOT appear
> > > to be valid C++ code
> > 
> > I've just managed to compile:
> > 
> > typedef struct foo foo;
> > 
> > with g++, version 2.95.2.  So it *is* valid C++.  I don't understand
> > why G++ is complaining about it.
> 
> YES! this is valid; what's NOT is
> 
> typedef struct foo* foo;
>   ^___ notice the '*' there.
> 
> canopus{SoftWrks}: echo "typedef struct foo* foo;" > tst.cpp
> canopus{SoftWrks}: gcc -c tst.cpp
> tst.cpp:1: conflicting types for `typedef struct foo * foo'
> tst.cpp:1: previous declaration as `struct foo'
> canopus{SoftWrks}: 
> 
> > 
> > If some widely used C++ compiler fails to compile it, for example,
> > when ltdl.h is in its standard header-file search path, then we may
> > have a good reason to change it.  But first I want to understand the
> > problem, so that it can at least be documented.
> 
> ALL C++ comilers should choke on this. AND as I say in my 
> previous mail it is VERY misleading to typedef a pointer to 
> something with the same name as this something.
> 
> Of course, as I've also said earlier, I don't have the latest 
> CVS libtool, so I take for granted what the initial message 
> said, that is the offending code is
> typedef struct lt_dlhandle *lt_dlhandle;
> 
> If there is no '*', all is OK of course.
> 
> 
>   Bernard
> 
> 
> Bernard Dautrevaux
> Microprocess Ingenierie
> 97 bis, rue de Colombes
> 92400 COURBEVOIE
> FRANCE
> Tel:  +33 (0) 1 47 68 80 80
> Fax:  +33 (0) 1 47 88 97 85
> e-mail:   [EMAIL PROTECTED]
>   [EMAIL PROTECTED]
>  
> 

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool



libtool & AIX

2000-11-29 Thread WHarms



I have tried to create a working example for shared libs on AIX4.2 and succeded. 
unfortunaly i dont have the time to translate my findings into libtools.
doese sombody care about the AIX port ? i can send him everything i have here.

walter




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool



Re: Problem with ltdl.h

2000-11-29 Thread Gary V. Vaughan

On Wed, Nov 29, 2000 at 01:01:23AM -0200, Alexandre Oliva wrote:
> On Nov 28, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> 
> > How about we simply change the name of the struct to lt_handlerecord
> > or something?
> 
> I prefer `something' :-)
> 
> How about `typedef struct lt_dlhandle_struct lt_dlhandle'?

Done!
-- 
  ___  _   ___   __  _ mailto: [EMAIL PROTECTED]
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___   [EMAIL PROTECTED] 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/  /___/  gpg public key:
http://www.oranda.demon.co.uk   http://www.oranda.demon.co.uk/key.asc

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool



Re: rpath command?

2000-11-29 Thread Olly Betts

In message <[EMAIL PROTECTED]>, Alexandre Oliva writes:
>[linking a library from other libraries with no object files]
>
>The point is that this just can't be done portably.

Since libtool's major purpose is to allow libraries to be built using a
portable interface, perhaps it should take care of this for the developer?

So on platforms where this doesn't work, perhaps libtool should add a dummy
file implicitly, rather than the developer having to implement the bodge
themselves?

>(ii) automake wouldn't know which compiler/linker to use for the
>library you're creating.  Specifying one or more source files is
>supposed to give automake a clue on which languages are being used in
>the sub-libraries.

This would be an obstacle to libtool creating the bodge file, but the .la
file could be extended to contain information about languages used in a
libtool library.

Cheers,
Olly

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool