Re: Problem with ltdl.h
On Wed, 29 Nov 2000, Gary V. Vaughan wrote: 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! Thanks. It works find now. -- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Problem with ltdl.h
-Original Message- From: Kevin Atkinson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 9:01 AM To: [EMAIL PROTECTED] Subject: Re: Problem with ltdl.h On Tue, 28 Nov 2000, Kevin Atkinson wrote: I just updated to the latest CVS version of libtool and I noticed two problems. 1) Even though I defined LT_NON_POSIX_NAMESPACE I still can't get lt_ptr_t to work. After looking at the header file I discovered the really is LT_FUBAR_NAMESPACE. Either the docs or the header files need to be changed 2) I keep on getting... /usr/local/include/ltdl.h:143: conflicting types for `typedef struct lt_dlhandle *lt_dlhandle' /usr/local/include/ltdl.h:143: previous declaration as `struct lt_dlhandle' I tried the affending line on egcs 1.1 gcc 2.95 and the gcc included in RedHat 7.0 and all of them give the same error. I should add that this works with C code but not in C++ code. Ooooh... Now I understand better: this diagnostic is due to the fact that in C++ struct lt_dlhandle automatically define a TYPENAME i.e. makes an implicit typedef struct lt_dlhandle lt_dlhandle; Then the explicit typedef struct lt_dlhandle* lt_dlhandle; defining the TYPENAME lt_dlhandle to be a pointer-to struct lt_dlhandle creates a conflict. I must say that although this is perfect C code, it's nevertheless highly questionable... It's kinda #define ADD(a, b) ((a) - (b)) ^ | This is not an error and was intentional to show some perfectly legal code that I would never accept if a programmer do that in my team ;-0 To be coherent, either the explicit typedef should read typedef struct lt_dlhandle* lt_dlhandle_ptr; or typedef struct lt_dlhandle* lt_dlhandle_handle; or the struct name is not good and everything should read: typedef struct lt_dl* lt_dlhandle; but clearly here we have a naming problem :-) I don't know from where this problem comes; I'm using a quite recent CVS-libtool (from beginning of october I think) and do not have this problem. HTH 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
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.
I don't know from where this problem comes; I'm using a quite recent
CVS-libtool (from beginning of october I think) and do not have this
problem.
Maybe this is only a problem in system headers? (GCC makes
distinction between headers in standard search PATHs and those
introduced by -I switches)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem with ltdl.h
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. It does NOT appear to be valid C++ code, thus when the header file is used in C++ programs it prevents them from being compiled. --- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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.
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.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem with ltdl.h
On 28 Nov 2000, Alexandre Oliva wrote: On Nov 28, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote: It does NOT appear to be valid C++ code I've just managed to compile: typedef struct foo foo; Yes that will compile but typedef struct foo * foo Won't, which is what the line in question looks like. --- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem with ltdl.h
On Tue, Nov 28, 2000 at 08:53:00PM -0200, Alexandre Oliva wrote: 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. 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. I introduced this problem when getting rid of the `_t' suffixes, where the line used to say: typedef struct lt_dlhandle *lt_dlhandle_t; which is fine because the explicit typedef has a different name to the implicit C++ typedef. Now that the _t has gone, a C++ compiler has two conflicting definitions for lt_dlhandle: typedef struct lt_dlhandle lt_dlhandle_t; typedef struct lt_dlhandle *lt_dlhandle_t; The first implicit one created by the compiler and the second from the code. I must say that I don't care much for `typedef foo *foo', and would be happy to remove the inderection and fix all of the exported functions. I fear this will break the API too radically -- e.g.: lt_dlhandle *lt_dlopen (...); Since the struct is an incomplete type anyway, and used like this only to remove the typecasting inside libltdl that would be necessary if we used: typedef lt_ptr *lt_dlhandle_t; How about we simply change the name of the struct to lt_handlerecord or something? Cheers, Gary. -- ___ _ ___ __ _ 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: Problem with ltdl.h
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'?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Problem with ltdl.h
On Tue, 28 Nov 2000, Kevin Atkinson wrote: I just updated to the latest CVS version of libtool and I noticed two problems. 1) Even though I defined LT_NON_POSIX_NAMESPACE I still can't get lt_ptr_t to work. After looking at the header file I discovered the really is LT_FUBAR_NAMESPACE. Either the docs or the header files need to be changed 2) I keep on getting... /usr/local/include/ltdl.h:143: conflicting types for `typedef struct lt_dlhandle *lt_dlhandle' /usr/local/include/ltdl.h:143: previous declaration as `struct lt_dlhandle' I tried the affending line on egcs 1.1 gcc 2.95 and the gcc included in RedHat 7.0 and all of them give the same error. I should add that this works with C code but not in C++ code. --- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
