Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Alexandre Oliva]

kuball  <kuball@zedo.fuedo.de> writes:

> On 10 Sep , Alexandre Oliva wrote:
>> kuball  <kuball@zedo.fuedo.de> writes:

>>> Looking at test.ii gives no answers, but new questions: there is no
>>> prototype for strcmp in the temp file, either. So why does the compiler
>>> warn about strncmp but not about strcmp???

>> Does string.h appear in the preprocessed output?  Is it read from
>> the directory where you expect it to live?

> No :(. It's read from /usr/local/lib/g++-include. But this are old
> include files belonging to gcc 2.7.

`make install' won't clean up the g++-include directory, because it
might contain something useful.

> Well, I specified
> 	--enable-version-specific-runtime-libs
> when buildng egcs.

But include-files are not libraries, right? :-)

> How come that the above directory is added to the default search
> path?

I guess it is searched by default.  Run `g++ -E -v - < /dev/null' to
check what the search path is.

> And how can I remove it from the default search path?

You may want to configure
--with-gxx-include-dir=/usr/local/include/eg++-1.1 or
--with-local-prefix=/usr/local/egcs or even with
--prefix=/usr/local/egcs-1.1

I'm not sure which one will fix your problem, but one of them should
do it, but each one will have different side-effects.  I myself prefer
to install each package in a separate directory, so I'd use the last
option.  However, this may not eliminate the possibility of having
/usr/local/lib/g++-include installed in the search path :-(

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[kuball]

On 12 Sep , Alexandre Oliva wrote:
> kuball  <kuball@zedo.fuedo.de> writes:
> 
>> On 10 Sep , Alexandre Oliva wrote:
>>> Does string.h appear in the preprocessed output?  Is it read from
>>> the directory where you expect it to live?
> 
>> No :(. It's read from /usr/local/lib/g++-include. But this are old
>> include files belonging to gcc 2.7.
> 
> `make install' won't clean up the g++-include directory, because it
> might contain something useful.

OK

>> Well, I specified
>> 	--enable-version-specific-runtime-libs
>> when buildng egcs.
> 
> But include-files are not libraries, right? :-)

>From the configure documentation:
--enable-version-specific-runtime-libs -- Specify that runtime libraries
should be installed in the compiler specific subdirectory
(${libsubdir}) rahter than the usual places. In addition, libstdc++'s
include files will be installed in ${libsubdir}/include/g++ unless you
overruled it [...]. Using this option is particularly useful if you
intend to use several versions of egcs/gcc in parallel.

>> How come that the above directory is added to the default search
>> path?
> 
> I guess it is searched by default.  Run `g++ -E -v - < /dev/null' to
> check what the search path is.

Yes, but why is /usr/local/lib/g++-include in the default path?
IMHO when using the above option the configure script should treat all
other g++ include directories as containing potentially harmful stuff.

>> And how can I remove it from the default search path?
> 
> You may want to configure
> --with-gxx-include-dir=/usr/local/include/eg++-1.1 or
> --with-local-prefix=/usr/local/egcs or even with
> --prefix=/usr/local/egcs-1.1
> 
> I'm not sure which one will fix your problem, but one of them should
> do it, but each one will have different side-effects.  I myself prefer
> to install each package in a separate directory, so I'd use the last
> option.  However, this may not eliminate the possibility of having
> /usr/local/lib/g++-include installed in the search path :-(

Meanwhile I just renamed the directory with the old include files ;).


Martin Kuball

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Jeffrey A Law]

  In message < orr9xelie0.fsf@tiete.dcc.unicamp.br >you write:
  > kuball  <kuball@zedo.fuedo.de> writes:
  > 
  > > but why is /usr/local/lib/g++-include in the default path?
  > 
  > I guess it is obtained from the local-prefix.
Nope.  It's from old_gxx_include_dir.

Support for old_gxx_include_dir should probably just go away.  The
g++ header files moved a while ago and trying to compile the very
old libg++ releases which use the old location probably doesn't work
anyway.

jeff

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Alexandre Oliva]

Jeffrey A Law <law@cygnus.com> writes:

> Support for old_gxx_include_dir should probably just go away.

Or should we just move /usr/local/g++ to somewhere *after* the
standard include path?  Otherwise, it would break installations of
poeple who have installed C++ include-files unrelated to g++ in
/usr/local/g++.

Which would you prefer me to do?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Jeffrey A Law]

  In message < orn281t5mf.fsf@tiete.dcc.unicamp.br >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > Support for old_gxx_include_dir should probably just go away.
  > 
  > Or should we just move /usr/local/g++ to somewhere *after* the
  > standard include path?  Otherwise, it would break installations of
  > poeple who have installed C++ include-files unrelated to g++ in
  > /usr/local/g++.
  > 
  > Which would you prefer me to do?
I'd prefer to see it go away, but I do understand the risks involved.

Moving it to last in the search path seems like a reasonable
compromise.

jeff

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

Jeffrey A Law <law@cygnus.com> writes:

>   In message < orn281t5mf.fsf@tiete.dcc.unicamp.br >you write:
>> Jeffrey A Law <law@cygnus.com> writes:
>> 
>> > Support for old_gxx_include_dir should probably just go away.

Agreed.  Unless we're going to support include/g++ in addition to
include/g++-2, which I'd prefer that we didn't.

Ok to install?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

[-- Attachment #2: cpppath.diff --]
[-- Type: text/x-diff, Size: 2787 bytes --]

for gcc/ChangeLog
	* cpplib.c: removed OLD_GPLUSPLUS_INCLUDE_DIR
	* cccp.c: ditto
	* Makefile.in (old_gxx_include_dir): removed

Index: gcc/cccp.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cccp.c,v
retrieving revision 1.33
diff -u -r1.33 cccp.c
--- cccp.c	1998/08/26 08:11:09	1.33
+++ cccp.c	1998/09/16 01:06:03
@@ -421,7 +421,6 @@
   = {
     /* Pick up GNU C++ specific include files.  */
     { GPLUSPLUS_INCLUDE_DIR, "G++", 1, 1 },
-    { OLD_GPLUSPLUS_INCLUDE_DIR, 0, 1, 1 },
 #ifdef CROSS_COMPILE
     /* This is the dir for fixincludes.  Put it just before
        the files that we fix.  */
Index: gcc/cpplib.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cpplib.c,v
retrieving revision 1.30
diff -u -r1.30 cpplib.c
--- cpplib.c	1998/08/26 08:11:15	1.30
+++ cpplib.c	1998/09/16 01:06:05
@@ -297,7 +297,6 @@
   = {
     /* Pick up GNU C++ specific include files.  */
     { GPLUSPLUS_INCLUDE_DIR, "G++", 1, 1 },
-    { OLD_GPLUSPLUS_INCLUDE_DIR, 0, 1, 1 },
 #ifdef CROSS_COMPILE
     /* This is the dir for fixincludes.  Put it just before
        the files that we fix.  */
Index: gcc/Makefile.in
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/Makefile.in,v
retrieving revision 1.170
diff -u -r1.170 Makefile.in
--- Makefile.in	1998/09/09 11:33:00	1.170
+++ Makefile.in	1998/09/16 01:06:06
@@ -272,10 +272,6 @@
 libsubdir = $(libdir)/gcc-lib/$(target_alias)/$(version)
 # Directory in which the compiler finds g++ includes.
 gxx_include_dir= @gxx_include_dir@
-# Directory in which the old g++ header files may be found.
-# The reason we use $(libdir)/g++-include rather than using libsubdir
-# is for compatibility with older versions of libg++.
-old_gxx_include_dir= $(libdir)/g++-include
 # Directory to search for site-specific includes.
 includedir = $(local_prefix)/include
 # assertdir is overridden in cross-make.
@@ -1864,7 +1860,6 @@
 	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 	  -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
 	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
-	  -DOLD_GPLUSPLUS_INCLUDE_DIR=\"$(old_gxx_include_dir)\" \
 	  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
 	  -DCROSS_INCLUDE_DIR=\"$(tooldir)/sys-include\" \
 	  -DTOOL_INCLUDE_DIR=\"$(tooldir)/include\" \
@@ -1883,7 +1878,6 @@
 	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 	  -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
 	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
-	  -DOLD_GPLUSPLUS_INCLUDE_DIR=\"$(old_gxx_include_dir)\" \
 	  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
 	  -DCROSS_INCLUDE_DIR=\"$(tooldir)/sys-include\" \
 	  -DTOOL_INCLUDE_DIR=\"$(tooldir)/include\" \

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Jeffrey A Law]

  In message < ord88wsw5j.fsf@tiete.dcc.unicamp.br >you write:
  > Agreed.  Unless we're going to support include/g++ in addition to
  > include/g++-2, which I'd prefer that we didn't.
  > 
  > Ok to install?
  > 
[ ... ]

  > for gcc/ChangeLog
  > 	* cpplib.c: removed OLD_GPLUSPLUS_INCLUDE_DIR
  > 	* cccp.c: ditto
  > 	* Makefile.in (old_gxx_include_dir): removed
Looks fine to me.

If we later find that this causes problems for some reason, we'll
just have to back it out and put it at the end of the include path.

jeff

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[kuball]

On 15 Sep , Jeffrey A Law wrote:
> 
> 
>   In message < orn281t5mf.fsf@tiete.dcc.unicamp.br >you write:
>   > Jeffrey A Law <law@cygnus.com> writes:
>   > 
>   > > Support for old_gxx_include_dir should probably just go away.
>   > 
>   > Or should we just move /usr/local/g++ to somewhere *after* the
>   > standard include path?  Otherwise, it would break installations of
>   > poeple who have installed C++ include-files unrelated to g++ in
>   > /usr/local/g++.
>   > 
>   > Which would you prefer me to do?
> I'd prefer to see it go away, but I do understand the risks involved.
> 
> Moving it to last in the search path seems like a reasonable
> compromise.

Why have it in the path at all? When somebody wants to use old stuff he
can use -I<directory> to add the directory to the search path.

Martin Kuball

egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[kuball]

I'm having a problem with the prototypes of the functions strncmp and
bcopy. The c++ compiler does not see them, the c compiler does.
Consider the following code:

#include <string.h>
#include <fstream.h>

//extern "C" int strncmp( const char*, const char*, int );
//extern "C" void bcopy( const char*, char*, int );

int
main( int, char** )
{
  char buf[40];
  bcopy( "This is a small test", buf, 21 );
  cout << buf << endl;

  cout << "test ncmp: " << strncmp( "this", "that", 2 ) << endl;
  cout << "test cmp: " << strcmp( "this", "that" ) << endl;

  return( 0 );  
}

compiling the above program gives the following warnings:

>gcc test.cpp -lstdc++
test.cpp: In function `int main(int, char **)':
test.cpp:12: warning: implicit declaration of function `int bcopy(...)'
test.cpp:15: warning: implicit declaration of function `int strncmp(...)'
>

though the resulting program works. Uncomenting the prototypes solves
the problem. Well, I looked into the string.h include file from

 /usr/local/lib/gcc-lib/alpha-dec-osf3.2/egcs-2.91.57/include

but found no notable difference between the prototype for strcmp and
strncmp. So, why does it not work?


Martin Kuball

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Alexandre Oliva]

kuball  <kuball@zedo.fuedo.de> writes:

> I'm having a problem with the prototypes of the functions strncmp and
> bcopy. The c++ compiler does not see them, the c compiler does.

Run the C/C++ compiler with the -save-temps flag, and look for the
declarations in the .i/.ii file it will produce.  You'll probably not
find them in the .ii, only in the .i, but finding out why the C++
preprocessor is eliminating these declarations is up to you.  Perhaps
an incorrect/outdated version of string.h in /usr/local/include/g++ ?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[kuball]

On 10 Sep , Alexandre Oliva wrote:
> kuball  <kuball@zedo.fuedo.de> writes:
> 
>> I'm having a problem with the prototypes of the functions strncmp and
>> bcopy. The c++ compiler does not see them, the c compiler does.
> 
> Run the C/C++ compiler with the -save-temps flag, and look for the
> declarations in the .i/.ii file it will produce.  You'll probably not
> find them in the .ii, only in the .i, but finding out why the C++
> preprocessor is eliminating these declarations is up to you.  Perhaps
> an incorrect/outdated version of string.h in /usr/local/include/g++ ?

Where can I find an explanation of the structure of the temp files?

Looking at test.ii gives no answers, but new questions: there is no
prototype for strcmp in the temp file, either. So why does the compiler
warn about strncmp but not about strcmp???

Martin Kuball

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files

[Alexandre Oliva]

kuball  <kuball@zedo.fuedo.de> writes:

> Where can I find an explanation of the structure of the temp files?

It is just the output of the preprocessor.  All macros and #includes
are expanded, and #ifs are resolved.  Lines starting with `#' indicate 
the line number and file their following lines come from.

> Looking at test.ii gives no answers, but new questions: there is no
> prototype for strcmp in the temp file, either. So why does the compiler
> warn about strncmp but not about strcmp???

Are you sure?  I haven't got access to an OSF/3.2 host, only to 4.0,
but strcmp shows up in the preprocessed output for me.  Does string.h
appear in the preprocessed output?  Is it read from the directory
where you expect it to live?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil