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
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: Problem with ltdl.h
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
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
Re: Problem with ltdl.h
On Nov 29, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote: > On 29 Nov 2000, 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'? > I will assume you ment. > typedef struct lt_dlhandle_struct * lt_dlhandle; Right. Oops :-) -- 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 29 Nov 2000, 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'? I will assume you ment. typedef struct lt_dlhandle_struct * lt_dlhandle; -- 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, "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, 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, Kevin Atkinson <[EMAIL PROTECTED]> wrote: > 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. Oops. I stand corrected. We do indeed have a problem. And now that you've pointed out the difference, I went back to read the C++ Standard and was reminded that the name of a class (or struct) cannot be `typedef'ed to a type other than the class (or struct) it names. So `typedef struct foo foo' is valid, but `typedef bar foo' is invalid unless bar is a synonym with `struct foo'. So, we indeed have to go fix ltdl.h. Thanks for your persistence :-) -- 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 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, 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, 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
> -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 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
Problem with ltdl.h
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. Thanks. --- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool