Mon 27 Jun 2016 07:48:28 PM UTC, comment #14:
Fixed on the default branch
http://hg.savannah.gnu.org/hgweb/octave/rev/6187b9ce8477
|
Mon 27 Jun 2016 07:27:25 PM UTC, comment #13:
I commented there.
I still think Octave's configure should be defensive and filter out all options except those beginning with -I, I'll take a look at making that change.
|
Mon 27 Jun 2016 06:47:56 PM UTC, comment #12:
There are some comments/questions by RedHat people on necessity of
@LARGEFILE@ and @PTHREAD_FLAGS@.
I have no idea, so I would appreciate if somebody can comment here or there.
https://bugzilla.redhat.com/show_bug.cgi?id=1350069
Dmitri.
|
Sat 25 Jun 2016 04:29:54 AM UTC, comment #11:
Mike,
I copied your bug report to redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=1350069
FYI.
Dmitri.
--
|
Fri 24 Jun 2016 07:34:32 PM UTC, comment #10:
Yeah, I think people sometimes misunderstand that the pkg-config is for users of the package, not a record of what options were used to build the package...
|
Fri 24 Jun 2016 07:07:07 PM UTC, comment #9:
I've filed a bug against the Debian fltk1.3 package
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828081
|
Fri 24 Jun 2016 06:14:01 PM UTC, comment #8:
On Debian:
|
Fri 24 Jun 2016 06:10:31 PM UTC, comment #7:
I do remember looking at fltk-config for some related issue or question recently. I remember thinking that maybe Octave should filter the output of fltk-config --cflags or --cxxflags and only use the -I options, ignore anything else with -D or -f or -specs.
IMHO those -D options should only be declared inside the library for building that library's modules, and not imposed on the API.
I agree this seems like a bug in fltk itself, the config program should be more conservative in what options it recommends users to apply.
Reopening for suggestions or patches. My suggestion would be to pipe the output through sed and only include words that start with "-I" in the FLTK_CPPFLAGS variable.
|
Fri 24 Jun 2016 05:26:04 PM UTC, comment #6:
What does
fltk-config-x86_64 --cxxflags
returns on Ubuntu / Debian ?
It is quite possible that thsi is a bug/fltk in fltk --
its config script inherits flags that were used to compile
fltk itself.
Perhaps octave should not use/rely on fltk-config to figure out
compiler flags, but I really do not understand configure magic
to make a constructive suggestion.
I just tried to reset FLTK_CONFIG and FLTK_CPPFLAGS to
empty strings and everything still works.
(-I/usr/include/freetype2 might be useful but we get it from elsewhere; I am not sure what are the possible problems due to not defining all the constants: -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT)
Dmitri.
--
|
Fri 24 Jun 2016 10:40:41 AM UTC, comment #5:
Right. Dmitri found exactly what happened to me.
Probably appropriate to place the blame on Fedora.
|
Fri 24 Jun 2016 05:49:58 AM UTC, comment #4:
Thanks for investigating Dmitri. I agree, this looks like a Fedora packaging bug, with the fltk package I suppose? That option is probably for internal use when building fltk and shouldn't be exposed to the user like that. Closing as invalid since there's nothing Octave can do about this, but please do report this to the Fedora bug tracker.
|
Fri 24 Jun 2016 05:35:55 AM UTC, comment #3:
The problem is that you get
fltk-config-x86_64 --cxxflags
-I/usr/include/freetype2 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT
But /usr/lib/rpm/redhat/redhat-hardened-cc1
is part of redhat-rpm-config.
It looks like a Fedora dependency bug.
Dmitri.
--
|
Thu 23 Jun 2016 11:06:45 PM UTC, comment #2:
Yes, I am sure. Pretty simple to test: Use dnf to
remove it, run configure, observe that FLTK is disabled,
install it, run configure, observe that FLTK is
enabled and works after build.
And, here is the code in configure that fails:
|
Thu 23 Jun 2016 10:42:57 PM UTC, comment #1:
Thanks, but I don't have enough information to do anything about this bug report.
Are you sure the rdhat-rpm-config package is responsible for your configure failure? If you uninstall only that package does it fail again? What is the exact error shown by configure?
There already are tests that Fortran works, both by itself and with the BLAS and LAPACK libraries, so I don't know how that's related.
|
Thu 23 Jun 2016 03:45:19 PM UTC, original submission:
The problem showed up as failure to build FLTK due to
missing GL/glext.h, but the real problem was that the
package redhat-rpm-config-40-2.fc24.noarch was missing.
This got removed in an overzealous cleanup after the update
from fc23 to fc24. This caused Fortran to fail at around line
20906 in configure.
Would a test that Fortran is working before trying to use it
be a good idea?
|