Sun 11 Sep 2016 02:49:18 AM UTC, comment #33:
I have confirmed that I could build octave with the QScintilla with the changeset shown in comment #32.
I appreciate for all persons who have been committed to the issue.
Please close this post.
|
Sat 10 Sep 2016 12:31:52 AM UTC, comment #32:
Pretty much the same patch then - pushed in mxe-octave
http://hg.octave.org/mxe-octave/rev/601ff07b0776
|
Fri 09 Sep 2016 09:55:49 PM UTC, comment #31:
The Debian qscintilla2 package is built with the patch linked here applied:
http://sources.debian.net/src/qscintilla2/2.9.3%2Bdfsg-3/debian/patches/build_debug_libs.patch/?hl=21#L21
|
Fri 09 Sep 2016 08:05:03 PM UTC, comment #30:
It kind of looks like an issue in qscintilla, but perhaps we are missing something in the compile.
I will ask on ascintilla mail list.
In the meantime, I will push the patch to qscintilla
|
Fri 09 Sep 2016 07:37:54 PM UTC, comment #29:
Huh. Is this a bug in qscintilla? I mean, they can't hide everything, can they? What symbols are exported? Are we using it incorrectly?
If we can solve the problem in mxe-octave, that's fine. But I guess this is going to start to fail in a lot of other distros soon unless they also disable the hide symbols option.
In any case, I'll check in my change since we should probably be checking for a lexer we actually care about, not SQL.
|
Fri 09 Sep 2016 07:10:02 PM UTC, comment #28:
Same issue with different class at that point
with hide_symbols set, qscintilla applied options -fvisibility=hidden -fvisibility-inlines-hidden to gcc.
|
Fri 09 Sep 2016 05:45:28 PM UTC, comment #27:
I'm trying now, but looking at libqscintilla2 with the hide_symbols option, the only entries I see using nm -D are imports from other libraries.
|
Fri 09 Sep 2016 04:09:57 PM UTC, comment #26:
OK, the configure test seems to pass with my native Debian build, but I didn't test with mxe-octave. John D, can you check to see whether this test works properly with the hide_symbols option?
|
Fri 09 Sep 2016 04:07:20 PM UTC, comment #25:
Right, we check for the header files for the Matlab and Octave lexers but work even if they don't exist. But we assume that the CPP lexer exists. I propose the attached patch. Testing now.
(file #38459)
|
Fri 09 Sep 2016 04:02:41 PM UTC, comment #24:
When I saw QsciLexerSQL, I assumed it was an arbitrary pick of a lexer that has existed for a long time in Qscintilla. Could also be a QsciLexerBash. We don't check for existence of a Matlab or Octave lexer because the editor is configured to work without them if using an older version of Qscintilla (at least that's how it looks to me).
http://hg.savannah.gnu.org/hgweb/octave/rev/637e3b7d6a56
|
Fri 09 Sep 2016 03:51:21 PM UTC, comment #23:
OK, now I'm curious to know why we are even checking for QsciLexerSQL. The only place that symbol is mentioned is in the test in m4/acinclude.m4. Do we really need this class specifically, or was this test added for some other reason? Hmm.
|
Fri 09 Sep 2016 03:35:40 PM UTC, comment #22:
Found issue in the build of qscintilla - they added a hide_symbols config option that is applied in 2.9.2 and 2.9.3.
If I disable that, it works ok
|
Fri 09 Sep 2016 01:07:13 PM UTC, comment #21:
And
nm -D usr/lib/libqscintilla2.so.12.0.1 | grep SQL #<- 2.9.1, shows a number of QSL entries
nm -D usr/lib/libqscintilla2.so.12.0.2 | grep SQL #<- 2.9.3 shows none
|
Fri 09 Sep 2016 12:29:38 PM UTC, comment #20:
creating a sample program based on the code from the octave configure test, I can reproducte the failure when building using qscintilla 2.9.3 (current) and 2.9.2, but it works ok in 2.9.1 (all built within mxe-octave)
So worst case would be go back to 2.9.1, but will continue to look at what changes in the build between them.
|
Fri 09 Sep 2016 11:45:54 AM UTC, comment #19:
I see the same on a native build in fedora:
Am looking into it
|
Fri 09 Sep 2016 10:22:07 AM UTC, comment #18:
I recently pushed a change for using qscintilla 2.9.3 [1] - prior to that it was probally an ommision on my part for the checksum
Playing around with native builds recently, I have also seen issues with Qt and where it attempts to pull some libraries from because it wasnt installing qmake, and then was using the system one. [2]
I had set a native build to run last night so will see if it has the same issue.
[1] http://hg.octave.org/mxe-octave/rev/7016a319a835
[2] http://hg.octave.org/mxe-octave/rev/5f6f60e3db31
|
Fri 09 Sep 2016 09:58:14 AM UTC, comment #17:
I have clone old mxe-octave (851b9f4a6b1c 09 Aug 2016).
But results are the same. The origin is not a mxe-octave revise nor octave code change.
nm -D results are similar to those are shown in the comment #15.
In the list by nm -D for libqscintilla2.so.12.xx installed from Ubuntu repository, I can find "QsciLexerSQL".
I cannot see it in libqscintilla2.so.12.xx built by mxe-octave native to linux.
|
Fri 09 Sep 2016 06:22:11 AM UTC, comment #16:
Sorry "I added filter by grep " was not executed.
|
Fri 09 Sep 2016 06:21:08 AM UTC, comment #15:
Mike Thanks for the reply
I cannot see symbols.
I added filter by grep
|
Fri 09 Sep 2016 03:50:14 AM UTC, comment #14:
jwe showed you how to do it with the static library.
Can you try "nm -D" for the shared library used for the native build?
|
Fri 09 Sep 2016 03:48:10 AM UTC, comment #13:
JWE Thanks for the nm command.
For native build, libqscintilla2.so.12.0.2
Another library e.g. libpng16.so.16.23.0
In the case of cross build of libqscintilla2:
On current mxe-octave, libqscintilla2 is not built correctly on the native build.
|
Fri 09 Sep 2016 12:15:37 AM UTC, comment #12:
Also, I noticed that the changeset to update to qscintilla 2.9.2 dropped the checksum on the tar file. Not sure why. Adding John D to the notification list for this bug report.
|
Fri 09 Sep 2016 12:13:20 AM UTC, comment #11:
Is there any other version of the libarary installed on the system in a directory where the compiler/linker might be searching?
To see exactly the commands that the compiler front end executes, you can copy the failed program text from the config.log file into a file, then run the command that failed in a shell window, adding -v so that g++ will show you the commands it executes. Maybe from that it will become apparent if there is another library that the compiler/linker is using?
You can use nm on the libqscintilla2.a file to see whether it actually does define the symbol. Something like
in the top-level mxe-octave directory should do it.
|
Thu 08 Sep 2016 11:46:04 PM UTC, comment #10:
Thanks for the change of title in proper way.
To comment #8
Please see the part of config.log
1. Is the libqscintilla2 library not installed in the correct direectory?
They are located in usr/lib in mxe-octave. The location is the same for other libraries.
2. Is the library installed but lacking certain symbols?
Perhaps so. I do not know how to check it. Please tell me the way.
3. Is another -L option needed to locate the library?
Perhaps not. Because error message does say that file not found.
If 2. is right, one has to specify what change break the mxe-octave for native build.
|
Thu 08 Sep 2016 11:20:41 PM UTC, comment #9:
I have tried to build stable branch (4.0.3) of octave on mxe-native build but similar error for Qscintilla detection in configure
At least, in August I could build stable branch octave for linux by
native build of mxe-octave.
Some change recently breaks in mxe-octave breaks native build.
|
Thu 08 Sep 2016 06:25:55 PM UTC, comment #8:
Lowering the priority since native build is not as important to the goals of mxe-octave at the moment.
You or someone who is working with the native build feature will have to figure out why the qscintilla library is not being found with the link command that is run by configure. Is the libqscintilla2 library not installed in the correct directory? Is the library installed but lacking certain symbols? Is another -L option needed to locate the library?
|
Thu 08 Sep 2016 02:20:19 AM UTC, comment #7:
For cross build, no problem occurred.
The same part of config.log for cross build.
This issue is native build specific.
|
Thu 08 Sep 2016 12:48:32 AM UTC, comment #6:
I'm not sure what's happening there. I just did a build with
mxe-octave: 8198522d93c4+ tip @
octave: 70aa2b362a31+ tip @
and the qscintilla library was found without this problem. But I was doing a cross build.
The modifications in my sources are not related to qscintilla.
|
Wed 07 Sep 2016 11:43:08 PM UTC, comment #5:
I looked into config.log
undefined reference to `QsciLexerSQL::~QsciLexerSQL()'
is origin of failure. Is something changed?
|
Wed 07 Sep 2016 10:49:43 PM UTC, comment #4:
You are right.
The mxe-octave (native) built and installed qscintilla but it was not recognized at configure of octave.
Thanks for the hint. I will struggle further.
|
Wed 07 Sep 2016 10:31:23 PM UTC, comment #3:
Was Octave built with or without Qscintilla? The mxe-octave/log/default-octave log file should contain the full build output and searching for scintilla should work.
Also
in Octave might be useful.
|
Wed 07 Sep 2016 10:28:19 PM UTC, comment #2:
Thanks for the reply.
I have already tried to delete ~/.config/octave/settings.
But it does not solved the issue.
|
Wed 07 Sep 2016 07:27:21 PM UTC, comment #1:
Did you wipe (or backup) .config/qtsettings and start Octave again?
I had similar problems lately, the undocked editor always appeared in a very small window in a corner of the screen - apparentlyits settings weren't properly retained.
Wiping qtsettings and reinstating my personal settings (at the cost of some work, yes) solved the issue .
|
Wed 07 Sep 2016 05:45:01 AM UTC, original submission:
On the recent dev. source, editor pane does not appear on octave mxe native build (e.g. 70aa2b362a31). Screenshot is attached.
For the mxe cross build for windows, such phenomena have not been occurred.
|