Bugzilla Bug 71678

The package name has changed from Blitz++-0.7.tar.gz to blitz-0.8.tar.gz. So I
changed the ebuild appropriately. I think the patch is no longer needed so I
commented it out.

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=44231) [edit]
blitz-0.8.ebuild

version bumped. Any problems add comment here.

ebuild does not install /usr/include/blitz/gnu/bzconfig.h

I have gcc-config 1.3.7, which doesn't define CXX=g++. If I do:

CXX=g++ emerge blitz;

then, the file gets installed.

I looked at some other bug entries, and according to http://bugs.gentoo.org/show_bug.cgi?id=67514 , CXX and CC shouldn't be defined, and ebuilds that depend on them should be considered broken, is this correct?

I have GCC 3.4.3.

alternative is using CC=$(tc-getCC) and CXX=$(tc-getCXX) in eclass
toolchain-funcs

I will look at this again.

I've added the (tc-getCXX) to the 0.8 ebuild. Please let me know if there are
any problems. It does add the missing header file.

Weird... for me it still doesn't add the missing header file, and g++ still
gets called as i686-pc-linux-gnu-g++ during configure (which, I believe, is
what causes this bug).

I did run "emerge --sync", and I can see the $(tc-getCXX) part in the ebuild.

I've removed CC and CXX from my environment and /etc/env.d/* and it still works
fine for me.

Please attach your environment, emerge info, Output from the configure section
of the compile, config.log and anything else that may be of use.

Yes I'm realy stuck as to what is happening here.

Created an attachment (id=46318) [edit]
my shell enviroment as root

Created an attachment (id=46319) [edit]
my emerge info

Created an attachment (id=46320) [edit]
blitz configure & compile output

Created an attachment (id=46321) [edit]
log for the ./configure script

I also added a "echo $(tc-getCXX)" line to the ebuild, before it runs
configure, and it prints out i686-pc-linux-gnu-g++, instead of g++.

I've descovered another problem (apart from having to CXX=g++):
if I try to reemerge blitz, the following happens:
make[3]: Entering directory `/var/tmp/portage/blitz-0.8/work/blitz-0.8/doc/doxygen'
make[3]: Nothing to be done for `install-exec-am'.
make  install-data-hook
make[4]: Entering directory `/var/tmp/portage/blitz-0.8/work/blitz-0.8/doc/doxygen'
Installing documentations into /var/tmp/portage/blitz-0.8/image//usr/share/doc/blitz-0.8
/bin/install: installing multiple files, but last argument, `/var/tmp/portage/blitz-0.8/image//usr/share/doc/blitz-0.8' is not a directory
Try `/bin/install --help' for more information.
make[4]: *** [install-data-hook] Error 1
make[4]: Leaving directory `/var/tmp/portage/blitz-0.8/work/blitz-0.8/doc/doxygen'
make[3]: *** [install-data-am] Error 2
make[3]: Leaving directory `/var/tmp/portage/blitz-0.8/work/blitz-0.8/doc/doxygen'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/var/tmp/portage/blitz-0.8/work/blitz-0.8/doc/doxygen'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/blitz-0.8/work/blitz-0.8/doc'
make: *** [install-recursive] Error 1

!!! ERROR: dev-libs/blitz-0.8 failed.
!!! Function src_install, Line 45, Exitcode 2

tux root # ls -al /var/tmp/portage/blitz-0.8/image/usr/   
total 16
drwxr-xr-x  4 root root 4096 Jan 13 15:44 .
drwxr-xr-x  3 root root 4096 Jan 13 15:44 ..
drwxr-xr-x  4 root root 4096 Jan 13 15:44 include
drwxr-xr-x  2 root root 4096 Jan 13 15:44 lib

If I first unmerge, there are no install problems.

Tiago de Paula Peixoto wrote:
> I also added a "echo $(tc-getCXX)" line to the ebuild, before it runs
> configure, and it prints out i686-pc-linux-gnu-g++, instead of g++.

I think he is right. When looking in configure (or in m4/ac_compiler_specific_header.m4) there only appears:
case "$CXX" in
[...]
  g++)      AX_PREFIX_CONFIG_H([blitz/gnu/bzconfig.h],[BZ])
            COMPILER_SPECIFIC_HEADER="gnu/bzconfig.h" ;;
[...]
esac
That's why the gnu subdirectory is not created.

So either $(tc-getCXX) should be g++ instead of i686-pc-linux-gnu-g++ or one would have to rewrite really many ebuilds (I don't think there are many configures that check for *g++ instead of g++)?

Thanks andy - I've patched the configure file for *g++). I've so created the
directory /usr/share/doc/${PF} before the install that should correct the other
fault.

Please reopen if these do not work. Thanks for the solution and your patience.