g++ can't locate iosfwd

g++ can't locate iosfwd

[Maciej Bliziński]

Continuing my work on Solaris packages, I came across a new problem.
I'm trying to compile the following code:

#include <iosfwd>
int main(void) {
}

The result:

$ /opt/csw/gcc4/bin/sparc-sun-solaris2.10-g++ 1.cpp
1.cpp:1:18: fatal error: iosfwd: No such file or directory
compilation terminated.

The file is there on the file system:

$ ls -l /opt/csw/gcc4/include/c++/*/iosfwd
-rw-r--r-- 1 root bin 6917 Aug 21 04:39 /opt/csw/gcc4/include/c++/4.6.1/iosfwd

Looking at the truss output, gcc tries to locate the header in wrong places:

22203:  stat64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include/iosfwd.gch",
0xFFBFF038) Err#2 ENOENT
22203:  open64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include/iosfwd",
O_RDONLY|O_NOCTTY) Err#2 ENOENT
22203:  stat64("/opt/csw/gcc4/include/iosfwd.gch", 0xFFBFF038) Err#2 ENOENT
22203:  open64("/opt/csw/gcc4/include/iosfwd", O_RDONLY|O_NOCTTY) Err#2 ENOENT
22203:  stat64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include-fixed/iosfwd.gch",
0xFFBFF038) Err#2 ENOENT
22203:  open64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include-fixed/iosfwd",
O_RDONLY|O_NOCTTY) Err#2 ENOENT
22203:  stat64("/usr/include/iosfwd.gch", 0xFFBFF038)   Err#2 ENOENT
22203:  open64("/usr/include/iosfwd", O_RDONLY|O_NOCTTY) Err#2 ENOENT

Where is the problem - are the header files misplaced, or is g++
looking in the wrong place?  Is there a recommended fix?

The build description is here:
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/branches/bootstrap-4.6/Makefile

My guess would be that the location of the header files is driven by
the --prefix or --includedir setting.  In my build the setting was:

--prefix=/opt/csw/gcc4
--includedir=/opt/csw/gcc4/include

...and other locations:
--exec_prefix=/opt/csw/gcc4
--bindir=/opt/csw/gcc4/bin
--sbindir=/opt/csw/gcc4/sbin
--libexecdir=/opt/csw/gcc4/libexec
--datadir=/opt/csw/gcc4/share
--sysconfdir=/etc/opt/csw/gcc4
--sharedstatedir=/opt/csw/gcc4/share
--localstatedir=/var/opt/csw/gcc4
--libdir=/opt/csw/lib
--infodir=/opt/csw/gcc4/share/info
--mandir=/opt/csw/gcc4/share/man

Are the above settings sensible?

Maciej

Re: g++ can't locate iosfwd

[Maciej Bliziński]

2011/8/21 Maciej Bliziński <maciej@opencsw.org>:
> 22203:  stat64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include/iosfwd.gch",
> 0xFFBFF038) Err#2 ENOENT
> 22203:  open64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include/iosfwd",
> O_RDONLY|O_NOCTTY) Err#2 ENOENT
> 22203:  stat64("/opt/csw/gcc4/include/iosfwd.gch", 0xFFBFF038) Err#2 ENOENT
> 22203:  open64("/opt/csw/gcc4/include/iosfwd", O_RDONLY|O_NOCTTY) Err#2 ENOENT
> 22203:  stat64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include-fixed/iosfwd.gch",
> 0xFFBFF038) Err#2 ENOENT
> 22203:  open64("/opt/csw/lib/gcc/sparc-sun-solaris2.10/4.6.1/include-fixed/iosfwd",
> O_RDONLY|O_NOCTTY) Err#2 ENOENT
> 22203:  stat64("/usr/include/iosfwd.gch", 0xFFBFF038)   Err#2 ENOENT
> 22203:  open64("/usr/include/iosfwd", O_RDONLY|O_NOCTTY) Err#2 ENOENT
>
> Where is the problem - are the header files misplaced, or is g++
> looking in the wrong place?

I compared the new build with the previous build of gcc (4.3.3), and
found how does gcc find this header file.  The files in the old build
are in the same place, but gcc is able to find them:

6414:   stat("/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../include/c++/4.3.3/iosfwd.gch",
0xFFBFF2B8) Err#2 ENOENT
6414:   open("/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../include/c++/4.3.3/iosfwd",
O_RDONLY|O_NOCTTY) = 4

Interestingly, it looks like the include files are found underneath
what was probably configured as libdir (PREFIX/lib).  In my build,
I've defined prefix to /opt/csw/gcc4, but I have set libdir to
/opt/csw/lib.  How does gcc get the idea to search
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../include/c++/4.3.3
for the include files? Is it defined in a file such as config.h?

Maciej

Re: g++ can't locate iosfwd

[Ian Lance Taylor]

Maciej Bliziński <maciej@opencsw.org> writes:

> Interestingly, it looks like the include files are found underneath
> what was probably configured as libdir (PREFIX/lib).  In my build,
> I've defined prefix to /opt/csw/gcc4, but I have set libdir to
> /opt/csw/lib.  How does gcc get the idea to search
> /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../include/c++/4.3.3
> for the include files? Is it defined in a file such as config.h?

Look for unlibsubdir and libsubdir_to_prefix in gcc/Makefile.in.

Ian

Re: g++ can't locate iosfwd

[Jonathan Wakely]

2011/8/21 Maciej Bliziński :
>
> My guess would be that the location of the header files is driven by
> the --prefix or --includedir setting.  In my build the setting was:
>
> --prefix=/opt/csw/gcc4
> --includedir=/opt/csw/gcc4/include
>
> ...and other locations:
> --exec_prefix=/opt/csw/gcc4
> --bindir=/opt/csw/gcc4/bin
> --sbindir=/opt/csw/gcc4/sbin
> --libexecdir=/opt/csw/gcc4/libexec
> --datadir=/opt/csw/gcc4/share
> --sysconfdir=/etc/opt/csw/gcc4
> --sharedstatedir=/opt/csw/gcc4/share
> --localstatedir=/var/opt/csw/gcc4
> --libdir=/opt/csw/lib
> --infodir=/opt/csw/gcc4/share/info
> --mandir=/opt/csw/gcc4/share/man
>
> Are the above settings sensible?

Since most of them are redundant (e.g. includedir defaults to
PREFIX/include) why are you bothering to override them?

Re: g++ can't locate iosfwd

[Maciej Bliziński]

2011/8/25 Ian Lance Taylor <iant@google.com>:
> Maciej Bliziński <maciej@opencsw.org> writes:
>
>> Interestingly, it looks like the include files are found underneath
>> what was probably configured as libdir (PREFIX/lib).  In my build,
>> I've defined prefix to /opt/csw/gcc4, but I have set libdir to
>> /opt/csw/lib.  How does gcc get the idea to search
>> /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/../../../../include/c++/4.3.3
>> for the include files? Is it defined in a file such as config.h?
>
> Look for unlibsubdir and libsubdir_to_prefix in gcc/Makefile.in.

Yes, looks like the libsubdir_to_prefix calculation goes wrong. Here
are the results for my build.  I added a target to print debug
information and ran it.

print-debug:
        @echo "prefix: $(prefix)"
        @echo "libdir: $(libdir)"
        @echo "unlibsubdir: $(unlibsubdir)"
        @echo "libsubdir_to_prefix: $(libsubdir_to_prefix)"

maciej@unstable10s [unstable10s]:~/src/opencsw/pkg/gcc4/branches/gccgo
> (cd work/solaris10-sparc/build-isa-sparcv8/objdir/gcc ; gmake
print-debug)
prefix: /opt/csw/gcc4
libdir: /opt/csw/lib
unlibsubdir: ../../..
libsubdir_to_prefix: ../../../../../../

If prefix is /opt/csw/gcc4 and libdir is /opt/csw/lib, then
libsubdir_to_prefix must have "gcc4" at the end, otherwise it's
invalid.

Perhaps I've run into this problem, because I'm setting the build in a
an unusual or wrong way.  What I want, is having the libraries in
/opt/csw/lib and the binaries in /opt/csw/gcc4/bin, and I don't care
much where everything else lives.  I can either set prefix to
/opt/csw/gcc4 and libdir to /opt/csw/lib, or prefix to /opt/csw and
some other settings to /opt/csw/gcc4. Which way is better?

Maciej

Re: g++ can't locate iosfwd

[Marc Glisse]

On Thu, 25 Aug 2011, Maciej Bliziński wrote:

> Perhaps I've run into this problem, because I'm setting the build in a
> an unusual or wrong way.  What I want, is having the libraries in
> /opt/csw/lib and the binaries in /opt/csw/gcc4/bin, and I don't care
> much where everything else lives.

Why do you want that? (there may be good reasons, but I don't know what 
they are)

The one thing with a position that needs checking is the 64bit libraries.

> I can either set prefix to
> /opt/csw/gcc4 and libdir to /opt/csw/lib, or prefix to /opt/csw and
> some other settings to /opt/csw/gcc4.

Or just set prefix and add a few symlinks afterwards, or...

-- 
Marc Glisse

Re: g++ can't locate iosfwd

[Maciej Bliziński]

2011/8/25 Marc Glisse <marc.glisse@inria.fr>:
> On Thu, 25 Aug 2011, Maciej Bliziński wrote:
>
>> Perhaps I've run into this problem, because I'm setting the build in a
>> an unusual or wrong way.  What I want, is having the libraries in
>> /opt/csw/lib and the binaries in /opt/csw/gcc4/bin, and I don't care
>> much where everything else lives.
>
> Why do you want that? (there may be good reasons, but I don't know what they
> are)

This discussion predates my involvement with OpenCSW, so I can
continue to package it as previously (everything under /opt/csw/gcc4),
or move it slightly forward with accordance with the new shared
libraries policy (libdir=/opt/csw/lib), or move it all to /opt/csw.
I've asked this question on the maintainers mailing list, and will see
if a consensus to move under /opt/csw appears or not.

http://lists.opencsw.org/pipermail/maintainers/2011-August/015263.html

> The one thing with a position that needs checking is the 64bit libraries.
>
>> I can either set prefix to
>> /opt/csw/gcc4 and libdir to /opt/csw/lib, or prefix to /opt/csw and
>> some other settings to /opt/csw/gcc4.
>
> Or just set prefix and add a few symlinks afterwards, or...

I think that one idea of installing gcc under /opt/csw/gcc4 was to
support an installation of multiple versions at the same time. For
example, gcc-3.x would go under /opt/csw/gcc3, gcc-4.x would go under
/opt/csw/gcc4, etc.

I'll see what's the outcome of the discussion at OpenCSW.

Maciej

Re: g++ can't locate iosfwd

[Ian Lance Taylor]

Maciej Bliziński <maciej@opencsw.org> writes:

> 2011/8/25 Marc Glisse <marc.glisse@inria.fr>:
>> On Thu, 25 Aug 2011, Maciej Bliziński wrote:
>>
>>> Perhaps I've run into this problem, because I'm setting the build in a
>>> an unusual or wrong way.  What I want, is having the libraries in
>>> /opt/csw/lib and the binaries in /opt/csw/gcc4/bin, and I don't care
>>> much where everything else lives.
>>
>> Why do you want that? (there may be good reasons, but I don't know what they
>> are)
>
> This discussion predates my involvement with OpenCSW, so I can
> continue to package it as previously (everything under /opt/csw/gcc4),
> or move it slightly forward with accordance with the new shared
> libraries policy (libdir=/opt/csw/lib), or move it all to /opt/csw.
> I've asked this question on the maintainers mailing list, and will see
> if a consensus to move under /opt/csw appears or not.
>
> http://lists.opencsw.org/pipermail/maintainers/2011-August/015263.html
>
>> The one thing with a position that needs checking is the 64bit libraries.
>>
>>> I can either set prefix to
>>> /opt/csw/gcc4 and libdir to /opt/csw/lib, or prefix to /opt/csw and
>>> some other settings to /opt/csw/gcc4.
>>
>> Or just set prefix and add a few symlinks afterwards, or...
>
> I think that one idea of installing gcc under /opt/csw/gcc4 was to
> support an installation of multiple versions at the same time. For
> example, gcc-3.x would go under /opt/csw/gcc3, gcc-4.x would go under
> /opt/csw/gcc4, etc.

To be clear, the header files and libraries are gcc version specific.
You can't use the gcc-4.x libstdc++ header files with gcc-3.x.

Ian

Re: g++ can't locate iosfwd

[Maciej Bliziński]

2011/8/26 Ian Lance Taylor <iant@google.com>:
>> I think that one idea of installing gcc under /opt/csw/gcc4 was to
>> support an installation of multiple versions at the same time. For
>> example, gcc-3.x would go under /opt/csw/gcc3, gcc-4.x would go under
>> /opt/csw/gcc4, etc.
>
> To be clear, the header files and libraries are gcc version specific.
> You can't use the gcc-4.x libstdc++ header files with gcc-3.x.

The headers are installed in a directory which includes the version,
so that should work well.  I have a question about libraries, though.
There are some libraries which haven't changed their SONAMEs since
gcc-3.x.  For example a compiled gcc-3.4.6 will produce
libstdc++.so.6, and so wil gcc-4.6.1. The theory is that if the SONAME
of a shared library doesn't change, applications should be able to
link against that library at runtime and run fine.  If that's true, I
should be able to compile and link a binary against libstdc++.so.6
using gcc.3.4.6, and then replace libstdc++.so.6 with the one built by
gcc-4.6.1.  Is this in fact possible?

Maciej

Re: g++ can't locate iosfwd

[Jonathan Wakely]

2011/8/27 Maciej Bliziński :
> There are some libraries which haven't changed their SONAMEs since
> gcc-3.x.  For example a compiled gcc-3.4.6 will produce
> libstdc++.so.6, and so wil gcc-4.6.1. The theory is that if the SONAME
> of a shared library doesn't change, applications should be able to
> link against that library at runtime and run fine.  If that's true, I
> should be able to compile and link a binary against libstdc++.so.6
> using gcc.3.4.6, and then replace libstdc++.so.6 with the one built by
> gcc-4.6.1.  Is this in fact possible?

Yes, it should work.

http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Be aware though that Symbol Versioning was not originally supported on
Solaris but is by recent GCC releases, so if it is enabled when you
build GCC that makes an incompatible libstdc++.so

Re: g++ can't locate iosfwd

[Maciej Bliziński]

2011/8/27 Jonathan Wakely <jwakely.gcc@gmail.com>:
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>
> Be aware though that Symbol Versioning was not originally supported on
> Solaris but is by recent GCC releases, so if it is enabled when you
> build GCC that makes an incompatible libstdc++.so

Can I test an existing binary whether it has enabled Symbol Versioning?

Maciej

Re: g++ can't locate iosfwd

[Jonathan Wakely]

2011/8/27 Maciej Bliziński:
> 2011/8/27 Jonathan Wakely <jwakely.gcc@gmail.com>:
>> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>>
>> Be aware though that Symbol Versioning was not originally supported on
>> Solaris but is by recent GCC releases, so if it is enabled when you
>> build GCC that makes an incompatible libstdc++.so
>
> Can I test an existing binary whether it has enabled Symbol Versioning?

You can use nm to see whether the symbols are versioned or not.