Hi,
in the process of trying to upgrade Gnuplot via Macports (v.2.3.3), a
long, long list of other packages needed to be (re)built as well, among
them apple-gcc42. That build fails after some time; the last part of the
logfile, which seems to contain the information pertaining to the
problem
On Aug 16, 2015, at 8:14 AM, Thomas Ruedas wrote:
in the process of trying to upgrade Gnuplot via Macports (v.2.3.3), a long,
long list of other packages needed to be (re)built as well, among them
apple-gcc42. That build fails after some time; the last part of the logfile,
which seems to
On Aug 15, 2015, at 1:48 PM, Ben Greenfield b...@cogs.com wrote:
On Aug 15, 2015, at 12:19 PM, Brandon Allbery allber...@gmail.com
mailto:allber...@gmail.com wrote:
On Sat, Aug 15, 2015 at 12:14 PM, Ben Greenfield b...@cogs.com
mailto:b...@cogs.com wrote:
gcc -fPIC -Wall -ggdb
On Sun, Aug 16, 2015 at 3:43 PM, Ben Greenfield b...@cogs.com wrote:
I think I fixed the problem by adding -L/opt/local/lib to the LDFLAGS in
macosx specific section.
Does that sound like the expected fix?
Depends. If it's based on autoconf then you sometimes have to read through
all the
On Aug 16, 2015, at 14:46, Brandon Allbery wrote:
On Sun, Aug 16, 2015 at 3:43 PM, Ben Greenfield wrote:
I think I fixed the problem by adding -L/opt/local/lib to the LDFLAGS in
macosx specific section.
Does that sound like the expected fix?
Depends. If it's based on autoconf then you
On Sun, Aug 16, 2015 at 5:05 PM, Ryan Schmidt ryandes...@macports.org
wrote:
I would answer this exactly the other way round: autoconf based build
systems are largely well behaved and will respond correctly to LDFLAGS
being set, though it's certainly possible to use autoconf incorrectly such
