Trying to compile php[ldap,oci8-instant-client] against oic 11.2.0.0.2 with my fix from bug #299558 comment #1 in place, I get this error message: /bin/sh /var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/libtool --silent --preserve-dup-deps --mode=compile x86_64-pc-linux-gnu-gcc -DLDAP_DEPRECATED=1 -Iext/ldap/ -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/ldap/ -DPHP_ATOM_INC -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/include -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/main -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12 -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/date/lib -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/mbstring/oniguruma -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/mbstring/libmbfl -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/oracle/11.2.0.0.2/client -I/usr/include/pspell -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/TSRM -I/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/Zend -I/usr/include -march=amdfam10 -O2 -ggdb -pipe -D_GNU_SOURCE -c /var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/ldap/ldap.c -o ext/ldap/ldap.lo In file included from /var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/l dap/php_ldap.h:30, from /var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/ldap/ldap.c:46: /usr/lib64/oracle/11.2.0.0.2/client/include/ldap.h:183: error: redefinition of 'struct berval' make: *** [ext/ldap/ldap.lo] Error 1 Looking at the preprocessed sources, I find # 43 "/usr/include/lber_types.h" 3 4 ... typedef unsigned long ber_len_t; ... # 207 "/usr/include/lber.h" 3 4 typedef struct berval { ber_len_t bv_len; char *bv_val; } BerValue; ... # 28 "/var/tmp/portage/dev-lang/php-5.2.12/work/php-5.2.12/ext/ldap/php_ldap.h" 2 # 1 "/usr/lib64/oracle/11.2.0.0.2/client/include/ldap.h" 1 3 # 104 "/usr/lib64/oracle/11.2.0.0.2/client/include/ldap.h" 3 ... struct berval { unsigned int bv_len; char *bv_val; }; So the two structures probably are seriously different on 64bit systems where long is different from int. I assume that the "#include <ldap.h>" in php_ldap.h should refer to /usr/include/ldap.h from openldap, not to the ldap.h from the oracle instantclient. Maybe the cleanest solution would either be to patch the instantclient to use a different file name for its own ldap header file, or to use the system-wide ldap.h and drop its own version. Not sure which, though.
This bug looks like the one I opened seperately - http://bugs.gentoo.org/show_bug.cgi?id=299689... in my case, on ~x86 (32bit)...
(In reply to comment #1) > This bug looks like the one I opened seperately - > http://bugs.gentoo.org/show_bug.cgi?id=299689... in my case, on ~x86 (32bit)... Agreed, bug #299689 is a duplicate of this one here. Other packages besides php are affected as well. I know xemacs for certain, but I guess there are many more packages trying to compile against both oracle-instantclient and ldap.
(In reply to comment #2) > (In reply to comment #1) > > This bug looks like the one I opened seperately - > > http://bugs.gentoo.org/show_bug.cgi?id=299689... in my case, on ~x86 (32bit)... > > Agreed, bug #299689 is a duplicate of this one here. Other packages besides php > are affected as well. I know xemacs for certain, but I guess there are many > more packages trying to compile against both oracle-instantclient and ldap. > I can confirm that samba-libs-3.4.3 fails, too.
The problem is that oracle-instantclient-basic adds C_INCLUDE_PATH pointing to its includes in /etc/env.d/50oracle-instantclient-basic. This then overrides the /usr/include/ldap.h. Also, they add their library to LDPATH in the same place. What were the idiots at Oracle thinking (if anything)? (This bit me when upgrading to net-fs/samba-libs-3.4.4.)
(In reply to comment #4) > The problem is that oracle-instantclient-basic adds C_INCLUDE_PATH pointing to > its includes in /etc/env.d/50oracle-instantclient-basic. This then overrides > the /usr/include/ldap.h. Also, they add their library to LDPATH in the same > place. Seeing as oracle-instantclient-basic doesn't provide any pkg-config metadata, how else could applications using it find it when compiling or executing? Simply based on the ORACLE_HOME environment setting, or by some hardcoded known path? Even if they did so, then apps actually using OCI would still have that directory on their include path, ergo would still have an entry denoting the wrong ldap.h. So the paths and environment variables seem all right to me, but the reuse of header file names is not. I still suggest to rename or remove ldap.h. Of course, if the package would install its header files directly into /usr/include, then we'd be notified of such issues via the package collisions mechanism, and we'd also avoid C_INCLUDE_PATH. Not sure if that would break builds expecting ${ORACLE_HOME}/include, though. A symlink might do. > What were the idiots at Oracle thinking (if anything)? The env.d file is created by the Gentoo ebuild, not the Oracle build process. It seems that rizzo introduced the LDPATH in 10.1.0.2_p1-r1, and radek added the C_INCLUDE_PATH in 10.1.0.3, both back in 2004.
(In reply to comment #5) > (In reply to comment #4) > > The problem is that oracle-instantclient-basic adds C_INCLUDE_PATH pointing to > > its includes in /etc/env.d/50oracle-instantclient-basic. This then overrides > > the /usr/include/ldap.h. Also, they add their library to LDPATH in the same > > place. > > Seeing as oracle-instantclient-basic doesn't provide any pkg-config metadata, > how else could applications using it find it when compiling or executing? > Simply based on the ORACLE_HOME environment setting, or by some hardcoded known > path? Even if they did so, then apps actually using OCI would still have that > directory on their include path, ergo would still have an entry denoting the > wrong ldap.h. > > So the paths and environment variables seem all right to me, but the reuse of > header file names is not. I still suggest to rename or remove ldap.h. > > Of course, if the package would install its header files directly into > /usr/include, then we'd be notified of such issues via the package collisions > mechanism, and we'd also avoid C_INCLUDE_PATH. Not sure if that would break > builds expecting ${ORACLE_HOME}/include, though. A symlink might do. I think it's a problem putting the Oracle Instant Client's include on C_INCLUDE_PATH in the ebuild. This should be left for the user to include it in the GCC command line or whatever he/she uses. Beside overriding ldap.h, this will also be confusing to anyone who isn't aware that _every_ compile now has Oracle Instant Client's includes. (It violates the principle of least surprise.) Similarly, the Oracle Instant Client's libraries shouldn't be put on the LDPATH by the ebuild. Instead, Oracle recommends that the administrator choose what to put on the LD_LIBRARY_PATH or PATH (See the Oracle Instant Client FAQ - http://www.oracle.com/technology/tech/oci/instantclient/ic-faq.html#A4990). > > What were the idiots at Oracle thinking (if anything)? > > The env.d file is created by the Gentoo ebuild, not the Oracle build process. > It seems that rizzo introduced the LDPATH in 10.1.0.2_p1-r1, and radek added > the C_INCLUDE_PATH in 10.1.0.3, both back in 2004. I apologize for my intemperate remark. However, as explained above, I don't believe that the ebuild should modify C_INCLUDE_PATH or LDPATH for everyone. This should be done by the administrator only when it is used for the particular job (If this isn't changed, at least a prominent warning should be emitted by the ebuild, but it would be better not to modify the environment variable in the ebuild IMO).
Also dev-libs/apr-util-1.3.9 and mail-client/pine-4.64-r5 fail because of using oracle's headers
*** Bug 299689 has been marked as a duplicate of this bug. ***
Fixed in CVS.
patch info? What files / revisions?
