Opened 10 years ago
Closed 10 years ago
#480 closed bug (fixed)
Problems compiling on Solaris because of -I/usr/local/include
Reported by: | Owned by: | hannes | |
---|---|---|---|
Priority: | major | Milestone: | 3-2-0 and higher |
Component: | dontKnow | Version: | 3-1-5 |
Keywords: | Cc: |
Description
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.
Change History (9)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
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?
comment:3 Changed 10 years ago by
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.
comment:4 Changed 10 years ago by
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
comment:5 Changed 10 years ago by
- 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...
comment:6 Changed 10 years ago by
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).
comment:7 Changed 10 years ago by
Sorry for splitting the post, but trac does not like the bunches of http links I included otherwise.
comment:8 Changed 10 years ago by
Owner: | changed from somebody to hannes |
---|
comment:9 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
/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.
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.