Problems compiling on Solaris because of -I/usr/local/include

[Jean-Pierre Flori <jpflori@…>]

Dear all,

While trying to compile Singular-3-1-5, I had troubles on Solaris because the headers from the built from scratch FSF GCC 4.7.2 I use are conflicting with some headers located in /usr/local/include (and I have no control over what is there, I'm no admin on the machine, so even if it is considered that these headers are broken, they will always get picked up on tis system). See ​https://groups.google.com/d/msg/sage-release/1felF4mvFMM/L-lSYD2u2I8J for some errors I get.

Is it really necessary to append (maybe prepending would be less harmful, don't know) -I/usr/local/include to CPPFLAGS and -L/usr/local/lib to LDFLAGS in Singular/configure[.in] and libfac/Makefile.dist (not sure this second one is harmful, but I removed it anyway)?

Without them everything compiles fine on Solaris.

And from what I quickly gathered on my other systems, there is nothing in /usr/local/include which gets picked up anyway.

[Jean-Pierre Flori <jpflori@…>]

Ok, so we have been discussing this extensively on Sage's trac server at ​http://trac.sagemath.org/sage_trac/ticket/14429, especially from comment 11 at ​http://trac.sagemath.org/sage_trac/ticket/14429#comment:11.

[Jean-Pierre Flori <jpflori@…>]

I'd say there two main questions/answers there:

• is it sensible to add -I/usr/local/include to CPPFLAGS and -L/usr/local/lib to LDFLAGS ?
• when and why was it added to Singular?

[Jean-Pierre Flori <jpflori@…>]

The second question is the most easy one and should by itself show what to do with this ticket. The first one is more trickier.

[Jean-Pierre Flori <jpflori@…>]

So for the second one:

• gcc 2.95 was kind of broken and installed stuff in "prefix"/include but failed to search for headers there, see ​http://gcc.gnu.org/ml/gcc/1999-07n/msg00958.html, ​http://gcc.gnu.org/ml/gcc-patches/1999-07n/msg00489.html and ​http://gcc.gnu.org/ml/gcc-patches/1999-05n/msg00477.html.
• whence the fix to add -I/usr/local/include to CPPFLAGS in Singular (note that would only save system-wide gcc's) at ​https://github.com/Singular/Sources/commit/a70441f0dcfb30cac8902851f41619cefa564903

[Jean-Pierre Flori <jpflori@…>]

• and when a fixed gcc3 went out, this fix was filtered out, see ​https://github.com/Singular/Sources/commit/833e11faeedd415ba185a7a678e4dcbe674720c3#Singular/configure.in
• now we are at gcc 4.x, and I don't think any stuff still uses GCC 2.95, especially that it's broken, and recent (3.x or 4.x) are smart enough to look in "prefix"/include for headers by themselves (in fact they look in "libdir"/gcc/"target"/"version"/include, "prefix"/include, "libdir"/gcc/"target"/"version"/include-fixed, /usr/include/"target", and usr/include in that order by default), see ​http://trac.sagemath.org/sage_trac/ticket/14429#comment:22 for some data
• so I guess the part about CPPFLAGS and LDFLAGS in Singular should reflect all of the above, i.e. only add -I/usr/local/include and -L/usr/local/lib if gcc version is 2.95, or you could even discard this fix...

[Jean-Pierre Flori <jpflori@…>]

For the first question, my opinion is that most system-wide packages install under /usr, and most user compiled ones under /usr/local. So if a user wants to use software he deliberatly installed under /usr/local he should be smart enough to add -I/usr/local/include and -L/usr/local/lib by himself. If those are added automagically, a system-wide gcc could find there incompatible headers from another gcc that the user installed but does not want to use currently. But that's only my personal view and I hope the first point will convince you to change the current behavior and so fix Singular install on my system (which is kind of borken I admit).

[Jean-Pierre Flori <jpflori@…>]

Sorry for splitting the post, but trac does not like the bunches of http links I included otherwise.

[hannes]

/usr/local is the default place for all GNU software (like GMP, readline, etc). But it is acceptable to add -I... and -L during configure if some dumb systems have problems with this standard paths. So we removed /usr/local/.. from the default configure options.