Replaced the -lqt option with -ltqt-mt, since libqt.so is missing.
Also added ebuild tqscintilla. This tqt fix is required to implement the tqscintilla assembly.
Added fixes for tqt:
1. For tqt-14.0.11 TQTDIR is changed to QTDIR
2. Replaced the `-lqt` option with `-ltqt-mt`, since `libqt.so` is missing.
Also added ebuild tqscintilla. This tqt fix is required to implement the tqscintilla assembly.
This looks suspicious. The value -lqt is set for QMAKE_LIBS_QT => built without threads support, while -ltqt-mt is set for QMAKE_LIBS_QT_THREAD => built with threads support, which is correct. Therefore, it seems that a QMAKE_LIBS_QT is incorrectly used elsewhere instead of QMAKE_LIBS_QT_THREAD, and this fix hides the real problem.
This looks suspicious. The value `-lqt` is set for `QMAKE_LIBS_QT` => built without threads support, while `-ltqt-mt` is set for `QMAKE_LIBS_QT_THREAD` => built with threads support, which is correct. Therefore, it seems that a `QMAKE_LIBS_QT` is incorrectly used elsewhere instead of `QMAKE_LIBS_QT_THREAD`, and this fix hides the real problem.
This looks suspicious. The value -lqt is set for QMAKE_LIBS_QT => built without threads support, while -ltqt-mt is set for QMAKE_LIBS_QT_THREAD => built with threads support, which is correct. Therefore, it seems that a QMAKE_LIBS_QT is incorrectly used elsewhere instead of QMAKE_LIBS_QT_THREAD, and this fix hides the real problem.
But as far as I understand, tqt does not support the assembly of two options simultaneously with and without multithreading. The gentoo tqt build only uses multithreading. That is, either the libqt.so library is created or libtqt-mt.so is created. It's just that the TARGET variable is overridden in the src/qt.pro file when building with thread. Having an unused QMAKE_LIBS_QT available creates more problems than benefits. libtqt-mt.so library uses the same functions as libqt.so
> This looks suspicious. The value -lqt is set for QMAKE_LIBS_QT => built without threads support, while -ltqt-mt is set for QMAKE_LIBS_QT_THREAD => built with threads support, which is correct. Therefore, it seems that a QMAKE_LIBS_QT is incorrectly used elsewhere instead of QMAKE_LIBS_QT_THREAD, and this fix hides the real problem.
But as far as I understand, tqt does not support the assembly of two options simultaneously with and without multithreading. The gentoo tqt build only uses multithreading. That is, either the `libqt.so` library is created or `libtqt-mt.so` is created. It's just that the `TARGET` variable is overridden in the `src/qt.pro` file when building with `thread`. Having an unused `QMAKE_LIBS_QT` available creates more problems than benefits. `libtqt-mt.so` library uses the same functions as `libqt.so`
Yes, certainly, TQt is built either with the support of the threads or not (which is a state that no one does perform for a long time, so with an uncertain result). But never both at the same time.
However, I probably see the cause of the problem in tqscintilla. There is not used variable QMAKESPEC, so it is possible that an incorrect mkspec file is selected and therefore the building is performed with incorrect configuration.
Please, you can verify what mkspec file is selected for building tqscintilla? Is it the same as it is used to build TQt?
Yes, certainly, TQt is built either with the support of the threads or not (which is a state that no one does perform for a long time, so with an uncertain result). But never both at the same time.
However, I probably see the cause of the problem in tqscintilla. There is not used variable `QMAKESPEC`, so it is possible that an incorrect mkspec file is selected and therefore the building is performed with incorrect configuration.
Please, you can verify what mkspec file is selected for building tqscintilla? Is it the same as it is used to build TQt?
However, I probably see the cause of the problem in tqscintilla. There is not used variable QMAKESPEC, so it is possible that an incorrect mkspec file is selected and therefore the building is performed with incorrect configuration.
The thread parameter is missing, hence the use of the QMAKE_LIBS_QT variable. The only difference in usage is the added thread option.
> However, I probably see the cause of the problem in tqscintilla. There is not used variable QMAKESPEC, so it is possible that an incorrect mkspec file is selected and therefore the building is performed with incorrect configuration.
```
$ grep QMAKESPEC /usr/tqt3/.qmake.cache
QMAKESPEC = linux-g++-64
$ grep -R linux-g++-64 /usr/tqt3/mkspecs/default/qmake.conf
# qmake configuration for linux-g++-64
```
Of course, the same is used as for installation.
```
# cd tqscintilla-14.0.11/designer
# grep CONFIG designer.pro
CONFIG += qt warn_on release plugin
```
The `thread` parameter is missing, hence the use of the `QMAKE_LIBS_QT` variable. The only difference in usage is the added `thread` option.
It is strange that linux-g++ uses CONFIG += threads in the default state, while linux-g++-64 not. Similarly, mkspecs for FreeBSD do not set threads config, even though it is built with threads support. It looks like a thing that would be good to fix.
If you add threads to CONFIG in tqscintilla, it builds okay?
It is strange that `linux-g++` uses `CONFIG += threads` in the default state, while `linux-g++-64` not. Similarly, mkspecs for FreeBSD do not set `threads` config, even though it is built with threads support. It looks like a thing that would be good to fix.
If you add `threads` to `CONFIG` in tqscintilla, it builds okay?
If you add threads to CONFIG in tqscintilla, it builds okay?
Yes of course the build is ok. Only the parameter is called thead without the ending s. Hmm, as an option, I can add treadto inux-g++-64
> If you add threads to CONFIG in tqscintilla, it builds okay?
Yes of course the build is ok. Only the parameter is called `thead` without the ending s. Hmm, as an option, I can add `tread`to `inux-g++-64`
If you add threads to CONFIG in tqscintilla, it builds okay?
Yes of course the build is ok. Only the parameter is called thead without the ending s. Hmm, as an option, I can add treadto linux-g++-64
Yes, adding thread to the used mkspec file seems like a good idea. We probably do this then also in TQt.
> > If you add threads to CONFIG in tqscintilla, it builds okay?
>
> Yes of course the build is ok. Only the parameter is called `thead` without the ending s. Hmm, as an option, I can add `tread`to `linux-g++-64`
Yes, adding `thread` to the used mkspec file seems like a good idea. We probably do this then also in TQt.
SlavekB
Added fixes for tqt:
-lqtoption with-ltqt-mt, sincelibqt.sois missing.Also added ebuild tqscintilla. This tqt fix is required to implement the tqscintilla assembly.
I believe that regarding
-lqtwe need to search for a real cause elsewhere – see comment.sed -i -e "s:\$(TQTDIR):${TQTBASE}:" || diesed -i -e "s:\$(QTDIR):${TQTBASE}:" || diefind "${D}${TQTBASE}/mkspecs" -name qmake.conf | xargs \sed -i -e "s:-lqt:-ltqt-mt:" || dieThis looks suspicious. The value
-lqtis set forQMAKE_LIBS_QT=> built without threads support, while-ltqt-mtis set forQMAKE_LIBS_QT_THREAD=> built with threads support, which is correct. Therefore, it seems that aQMAKE_LIBS_QTis incorrectly used elsewhere instead ofQMAKE_LIBS_QT_THREAD, and this fix hides the real problem.But as far as I understand, tqt does not support the assembly of two options simultaneously with and without multithreading. The gentoo tqt build only uses multithreading. That is, either the
libqt.solibrary is created orlibtqt-mt.sois created. It's just that theTARGETvariable is overridden in thesrc/qt.profile when building withthread. Having an unusedQMAKE_LIBS_QTavailable creates more problems than benefits.libtqt-mt.solibrary uses the same functions aslibqt.soYes, certainly, TQt is built either with the support of the threads or not (which is a state that no one does perform for a long time, so with an uncertain result). But never both at the same time.
However, I probably see the cause of the problem in tqscintilla. There is not used variable
QMAKESPEC, so it is possible that an incorrect mkspec file is selected and therefore the building is performed with incorrect configuration.Please, you can verify what mkspec file is selected for building tqscintilla? Is it the same as it is used to build TQt?
Of course, the same is used as for installation.
The
threadparameter is missing, hence the use of theQMAKE_LIBS_QTvariable. The only difference in usage is the addedthreadoption.It is strange that
linux-g++usesCONFIG += threadsin the default state, whilelinux-g++-64not. Similarly, mkspecs for FreeBSD do not setthreadsconfig, even though it is built with threads support. It looks like a thing that would be good to fix.If you add
threadstoCONFIGin tqscintilla, it builds okay?Yes of course the build is ok. Only the parameter is called
theadwithout the ending s. Hmm, as an option, I can addtreadtoinux-g++-64Yes, adding
threadto the used mkspec file seems like a good idea. We probably do this then also in TQt.b5e4ba76ceto5a593ebac32 years ago5a593ebac3todef40ef6d52 years agoAdded fixes to tqt, now added
threadand fixed build formysql/mariadb.Thank you, now the bug is not masked, but it was revealed.
def40ef6d5into master 2 years agoReviewers
def40ef6d5.