Opened 10 years ago

Closed 10 years ago

#480 closed bug (fixed)

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

Reported by: Jean-Pierre Flori <jpflori@…> Owned by: hannes
Priority: major Milestone: 3-2-0 and higher
Component: dontKnow Version: 3-1-5
Keywords: Cc:


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 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 Jean-Pierre Flori <jpflori@…>

Ok, so we have been discussing this extensively on Sage's trac server at, especially from comment 11 at

comment:2 Changed 10 years ago by 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?

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by Jean-Pierre Flori <jpflori@…>

So for the second one:

comment:5 Changed 10 years ago by Jean-Pierre Flori <jpflori@…>

  • and when a fixed gcc3 went out, this fix was filtered out, see
  • 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 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 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).

comment:7 Changed 10 years ago by Jean-Pierre Flori <jpflori@…>

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 ren

Owner: changed from somebody to hannes

comment:9 Changed 10 years ago by hannes

Resolution: fixed
Status: newclosed

/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.

Note: See TracTickets for help on using tickets.