Re: Compiling LyX 2.5 on macOS Sonoma

[Pavel Sanda]

On Sat, Jun 24, 2023 at 07:28:59AM +0200, Christoph Schmitz wrote:
> Hello,
> 
> Attached is my config.log.

The attachment looks corrupted. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Compiling LyX 2.5 on macOS Sonoma

[Christoph Schmitz]

Hello,

Attached is my config.log.

Chris

<>



> Am 21.06.2023 um 12:50 schrieb Jean-Marc Lasgouttes :
> 
> Le 21/06/2023 à 12:36, Christoph Schmitz a écrit :
>> Hello Scott,
>> Yes,
>> I deleted my local repository already a few times and started from scratch.
> 
> Hello,
> 
> Could you please send your config.log file?
> 
> JMarc
> 
>> These are the commands I use:
>> cd ~/chris/Git
>> git clone git://git.lyx.org/lyx LyX
>> cd LyX
>> ./autogen.sh
>> ./configure \
>> --with-version-suffix=-2.4 \
>> --with-libiconv-prefix=/usr \
>> --prefix=/Users/chris/Desktop/LyX.app \
>> --with-x=no \
>> --disable-stdlib-debug \
>> --with-included-hunspell \
>> --enable-qt6 \
>> --with-macos-deployment-target=13.0
>> make -j8 && make install-strip
>> Chris
>>> Am 21.06.2023 um 11:50 schrieb Scott Kostyshak :
>>> 
>>> On Wed, Jun 21, 2023 at 07:45:09AM +0200, Christoph Schmitz wrote:
 
 I have been unable to compile LyX 2.4 on macOS Sonoma for the past few 
 days. The error message I am receiving is as follows:
 
 ...
 Making all in qt
 /Library/Developer/CommandLineTools/usr/bin/make  all-am
 make[6]: Nothing to be done for `all-am'.
 Making all in .
 make[5]: Nothing to be done for `all-am'.
 Making all in .
  CHK  lyx_commit_hash.h
  CXXLDlyx
 Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  lyx::IconvProcessor::convert(char const*, unsigned long, char*, 
 unsigned long) in liblyxsupport.a(unicode.o)
  (anonymous namespace)::iconv_codecvt_facet::do_out(__mbstate_t&, 
 wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) 
 const in liblyxsupport.a(docstream.o)
  (anonymous namespace)::iconv_codecvt_facet::do_in(__mbstate_t&, char 
 const*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const in 
 liblyxsupport.a(docstream.o)
 (maybe you meant: 
 lyx::from_iconv_encoding(std::__1::basic_string>>> std::__1::char_traits, std::__1::allocator> const&, 
 std::__1::basic_string, 
 std::__1::allocator> const&), 
 lyx::to_iconv_encoding(std::__1::basic_string>>> std::__1::char_traits, std::__1::allocator> const&, 
 std::__1::basic_string, 
 std::__1::allocator> const&) , AffixMgr::get_iconvtable() const )
  "_iconv_close", referenced from:
  lyx::IconvProcessor::Handler::~Handler() in liblyxsupport.a(unicode.o)
  (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet() in 
 liblyxsupport.a(docstream.o)
  "_iconv_open", referenced from:
  lyx::IconvProcessor::init() in liblyxsupport.a(unicode.o)
  (anonymous 
 namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::__1::basic_string>>>  std::__1::char_traits, std::__1::allocator> const&, unsigned 
 int, unsigned long) in liblyxsupport.a(docstream.o)
 ld: symbol(s) not found for architecture x86_64
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)
 make[4]: *** [lyx] Error 1
 make[3]: *** [all-recursive] Error 1
 make[2]: *** [all] Error 2
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2
 
 I am attempting to compile LyX on macOS Sonoma, however, the issue I am 
 facing did not originate upon switching to Sonoma. Is there any advice on 
 what I could do to resolve this?
>>> 
>>> 
>>> Hi Chris,
>>> 
>>> Are you using a clean git repository and also building from scratch? What 
>>> were all the commands that you used (e.g., cmake command)
>>> 
>>> Scott
>>> 
>>> --
>>> lyx-devel mailing list
>>> lyx-devel@lists.lyx.org 
>>> http://lists.lyx.org/mailman/listinfo/lyx-devel 
>>> 
> 
> -- 
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Compiling LyX 2.5 on macOS Sonoma

[Jean-Marc Lasgouttes]

Le 21/06/2023 à 12:36, Christoph Schmitz a écrit :

Hello Scott,

Yes,

I deleted my local repository already a few times and started from scratch.


Hello,

Could you please send your config.log file?

JMarc



These are the commands I use:

cd ~/chris/Git

git clone git://git.lyx.org/lyx LyX

cd LyX

./autogen.sh

./configure \
--with-version-suffix=-2.4 \
--with-libiconv-prefix=/usr \
--prefix=/Users/chris/Desktop/LyX.app \
--with-x=no \
--disable-stdlib-debug \
--with-included-hunspell \
--enable-qt6 \
--with-macos-deployment-target=13.0

make -j8 && make install-strip

Chris



Am 21.06.2023 um 11:50 schrieb Scott Kostyshak :

On Wed, Jun 21, 2023 at 07:45:09AM +0200, Christoph Schmitz wrote:


I have been unable to compile LyX 2.4 on macOS Sonoma for the past 
few days. The error message I am receiving is as follows:


...
Making all in qt
/Library/Developer/CommandLineTools/usr/bin/make  all-am
make[6]: Nothing to be done for `all-am'.
Making all in .
make[5]: Nothing to be done for `all-am'.
Making all in .
 CHK  lyx_commit_hash.h
 CXXLD    lyx
Undefined symbols for architecture x86_64:
 "_iconv", referenced from:
 lyx::IconvProcessor::convert(char const*, unsigned long, char*, 
unsigned long) in liblyxsupport.a(unicode.o)
 (anonymous namespace)::iconv_codecvt_facet::do_out(__mbstate_t&, 
wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, 
char*&) const in liblyxsupport.a(docstream.o)
 (anonymous namespace)::iconv_codecvt_facet::do_in(__mbstate_t&, 
char const*, char const*, char const*&, wchar_t*, wchar_t*, 
wchar_t*&) const in liblyxsupport.a(docstream.o)
(maybe you meant: 
lyx::from_iconv_encoding(std::__1::basic_stringstd::__1::char_traits, std::__1::allocator> const&, 
std::__1::basic_string, 
std::__1::allocator> const&), 
lyx::to_iconv_encoding(std::__1::basic_stringstd::__1::char_traits, std::__1::allocator> const&, 
std::__1::basic_string, 
std::__1::allocator> const&) , AffixMgr::get_iconvtable() const )

 "_iconv_close", referenced from:
 lyx::IconvProcessor::Handler::~Handler() in 
liblyxsupport.a(unicode.o)
 (anonymous 
namespace)::iconv_codecvt_facet::~iconv_codecvt_facet() in 
liblyxsupport.a(docstream.o)

 "_iconv_open", referenced from:
 lyx::IconvProcessor::init() in liblyxsupport.a(unicode.o)
 (anonymous 
namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::__1::basic_string, std::__1::allocator> const&, unsigned int, unsigned long) in liblyxsupport.a(docstream.o)

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

make[4]: *** [lyx] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I am attempting to compile LyX on macOS Sonoma, however, the issue I 
am facing did not originate upon switching to Sonoma. Is there any 
advice on what I could do to resolve this?



Hi Chris,

Are you using a clean git repository and also building from scratch? 
What were all the commands that you used (e.g., cmake command)


Scott

--
lyx-devel mailing list
lyx-devel@lists.lyx.org 
http://lists.lyx.org/mailman/listinfo/lyx-devel 






--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Compiling LyX 2.5 on macOS Sonoma

[Christoph Schmitz]

Hello Scott,

Yes,

I deleted my local repository already a few times and started from scratch.

These are the commands I use:

cd ~/chris/Git

git clone git://git.lyx.org/lyx LyX

cd LyX

./autogen.sh

./configure \
--with-version-suffix=-2.4 \
--with-libiconv-prefix=/usr \
--prefix=/Users/chris/Desktop/LyX.app \
--with-x=no \
--disable-stdlib-debug \
--with-included-hunspell \
--enable-qt6 \
--with-macos-deployment-target=13.0

make -j8 && make install-strip

Chris


> Am 21.06.2023 um 11:50 schrieb Scott Kostyshak :
> 
> On Wed, Jun 21, 2023 at 07:45:09AM +0200, Christoph Schmitz wrote:
>> 
>> I have been unable to compile LyX 2.4 on macOS Sonoma for the past few days. 
>> The error message I am receiving is as follows:
>> 
>> ...
>> Making all in qt
>> /Library/Developer/CommandLineTools/usr/bin/make  all-am
>> make[6]: Nothing to be done for `all-am'.
>> Making all in .
>> make[5]: Nothing to be done for `all-am'.
>> Making all in .
>>  CHK  lyx_commit_hash.h
>>  CXXLDlyx
>> Undefined symbols for architecture x86_64:
>>  "_iconv", referenced from:
>>  lyx::IconvProcessor::convert(char const*, unsigned long, char*, 
>> unsigned long) in liblyxsupport.a(unicode.o)
>>  (anonymous namespace)::iconv_codecvt_facet::do_out(__mbstate_t&, 
>> wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const 
>> in liblyxsupport.a(docstream.o)
>>  (anonymous namespace)::iconv_codecvt_facet::do_in(__mbstate_t&, char 
>> const*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const in 
>> liblyxsupport.a(docstream.o)
>> (maybe you meant: lyx::from_iconv_encoding(std::__1::basic_string> std::__1::char_traits, std::__1::allocator> const&, 
>> std::__1::basic_string, 
>> std::__1::allocator> const&), 
>> lyx::to_iconv_encoding(std::__1::basic_string> std::__1::char_traits, std::__1::allocator> const&, 
>> std::__1::basic_string, 
>> std::__1::allocator> const&) , AffixMgr::get_iconvtable() const )
>>  "_iconv_close", referenced from:
>>  lyx::IconvProcessor::Handler::~Handler() in liblyxsupport.a(unicode.o)
>>  (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet() in 
>> liblyxsupport.a(docstream.o)
>>  "_iconv_open", referenced from:
>>  lyx::IconvProcessor::init() in liblyxsupport.a(unicode.o)
>>  (anonymous 
>> namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::__1::basic_string>  std::__1::char_traits, std::__1::allocator> const&, unsigned 
>> int, unsigned long) in liblyxsupport.a(docstream.o)
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> make[4]: *** [lyx] Error 1
>> make[3]: *** [all-recursive] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>> 
>> I am attempting to compile LyX on macOS Sonoma, however, the issue I am 
>> facing did not originate upon switching to Sonoma. Is there any advice on 
>> what I could do to resolve this?
> 
> 
> Hi Chris,
> 
> Are you using a clean git repository and also building from scratch? What 
> were all the commands that you used (e.g., cmake command)
> 
> Scott
> 
> -- 
> lyx-devel mailing list
> lyx-devel@lists.lyx.org 
> http://lists.lyx.org/mailman/listinfo/lyx-devel

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Compiling LyX 2.5 on macOS Sonoma

[Scott Kostyshak]

On Wed, Jun 21, 2023 at 07:45:09AM +0200, Christoph Schmitz wrote:
> 
> I have been unable to compile LyX 2.4 on macOS Sonoma for the past few days. 
> The error message I am receiving is as follows:
> 
> ...
> Making all in qt
> /Library/Developer/CommandLineTools/usr/bin/make  all-am
> make[6]: Nothing to be done for `all-am'.
> Making all in .
> make[5]: Nothing to be done for `all-am'.
> Making all in .
>   CHK  lyx_commit_hash.h
>   CXXLDlyx
> Undefined symbols for architecture x86_64:
>   "_iconv", referenced from:
>   lyx::IconvProcessor::convert(char const*, unsigned long, char*, 
> unsigned long) in liblyxsupport.a(unicode.o)
>   (anonymous namespace)::iconv_codecvt_facet::do_out(__mbstate_t&, 
> wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const 
> in liblyxsupport.a(docstream.o)
>   (anonymous namespace)::iconv_codecvt_facet::do_in(__mbstate_t&, char 
> const*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const in 
> liblyxsupport.a(docstream.o)
>  (maybe you meant: lyx::from_iconv_encoding(std::__1::basic_string std::__1::char_traits, std::__1::allocator> const&, 
> std::__1::basic_string, 
> std::__1::allocator> const&), 
> lyx::to_iconv_encoding(std::__1::basic_string std::__1::char_traits, std::__1::allocator> const&, 
> std::__1::basic_string, 
> std::__1::allocator> const&) , AffixMgr::get_iconvtable() const )
>   "_iconv_close", referenced from:
>   lyx::IconvProcessor::Handler::~Handler() in liblyxsupport.a(unicode.o)
>   (anonymous namespace)::iconv_codecvt_facet::~iconv_codecvt_facet() in 
> liblyxsupport.a(docstream.o)
>   "_iconv_open", referenced from:
>   lyx::IconvProcessor::init() in liblyxsupport.a(unicode.o)
>   (anonymous 
> namespace)::iconv_codecvt_facet::iconv_codecvt_facet(std::__1::basic_string  std::__1::char_traits, std::__1::allocator> const&, unsigned 
> int, unsigned long) in liblyxsupport.a(docstream.o)
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[4]: *** [lyx] Error 1
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> I am attempting to compile LyX on macOS Sonoma, however, the issue I am 
> facing did not originate upon switching to Sonoma. Is there any advice on 
> what I could do to resolve this?


Hi Chris,

Are you using a clean git repository and also building from scratch? What were 
all the commands that you used (e.g., cmake command)

Scott



signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: compiling LyX

[Jean-Marc Lasgouttes]

Le 11/11/2021 à 19:00, john kennan a écrit :

I don't know how to reply to messages on the list (I'm already subscribed)


Hello John,

What is the problem? That you answer to sender instead?

What are you using for your emails?

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: compiling LyX

[john kennan]

I don't know how to reply to messages on the list (I'm already subscribed)

Edited the wiki (https://wiki.lyx.org/Devel/Git) to say that one must
change to the lyx directory after the first couple of steps

John


On Thu, Nov 11, 2021 at 11:14 AM john kennan  wrote:

> Hi
>
> I'd like to be able to compile LyX (on Mac OS Big Sur).
>
> I tried following the instructions on https://wiki.lyx.org/Devel/Git
> Got as far as this:
>
> (base) jk@jkmac-3 ~ % git config --global user.name jkennan
> (base) jk@jkmac-3 ~ % git config --global user.email jken...@gmail.com
> (base) jk@jkmac-3 ~ %git checkout master
> fatal: not a git repository (or any of the parent directories): .git
>
> John Kennan
>
>
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: compiling LyX

[Scott Kostyshak]

On Thu, Nov 11, 2021 at 11:14:23AM -0600, john kennan wrote:
> Hi
> 
> I'd like to be able to compile LyX (on Mac OS Big Sur).
> 
> I tried following the instructions on https://wiki.lyx.org/Devel/Git
> Got as far as this:
> 
> (base) jk@jkmac-3 ~ % git config --global user.name jkennan
> (base) jk@jkmac-3 ~ % git config --global user.email jken...@gmail.com
> (base) jk@jkmac-3 ~ %git checkout master
> fatal: not a git repository (or any of the parent directories): .git
> 
> John Kennan

Hi John,

First you need to clone:

  git clone "git://git.lyx.org/lyx"

That will create a directory called "lyx" wherever you run that command.

After cloning, then you need to hope that Stephan can help you :). I
think he has a build script for compiling LyX on macOS.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Peter Kümmel]

Am 01.11.2015 um 22:02 schrieb Georg Baum:

Peter Kümmel wrote:


For iconv and hunspell one can find some CMakeLists.txt at github, not
ready for MSVC but usable as starting point. AFAIk zlib already ships
with cmake files.

Would it be an option to add tripped down iconv, hunspell and zlib sources
to lyx and to build them as static libraries like boost? Then the Windows
installer would only depend on ready-to-use binaries, maintained by other
projects.


If the license of those libs allows redistribution with the LyX sources,
then this would be an option IMHO if the size increase of the package would
not be too big. This would be easier to use than my suggestion, but in both
cases we would need somebody who keeps the sources up to date.


Georg




Hunspell:
License: GPL/LGPL/MPL tri-license.
Latest release date: 2014-06-02
http://hunspell.sourceforge.net/

libiconv:
License: GPL
Latest release date: 2011-08-07
https://www.gnu.org/software/libiconv/

zlib:
License: zlib (BSD/MIT like)
Latest release date: 2013-04-29
http://www.zlib.net/


Linking these libs into a GPL application is therefore no problem.
Sources also does not change very often, less then boost.
And the size is also not that big when only the files are
used needed to build the library.

Then I start to add the libs. Before I push I send an overview
of the changes.

Peter

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Georg Baum]

Peter Kümmel wrote:

> For iconv and hunspell one can find some CMakeLists.txt at github, not
> ready for MSVC but usable as starting point. AFAIk zlib already ships
> with cmake files.
> 
> Would it be an option to add tripped down iconv, hunspell and zlib sources
> to lyx and to build them as static libraries like boost? Then the Windows
> installer would only depend on ready-to-use binaries, maintained by other
> projects.

If the license of those libs allows redistribution with the LyX sources, 
then this would be an option IMHO if the size increase of the package would 
not be too big. This would be easier to use than my suggestion, but in both 
cases we would need somebody who keeps the sources up to date.


Georg

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Peter Kümmel]

Am 14.10.2015 um 21:52 schrieb Georg Baum:

David Hyde wrote:


I'm interested in looking into this at least a bit (may become deterred
if some dependency nightmare occurs!).  I've looked at the current MSVC
dependencies that are in the archive on sourceforge.  Which of these
are things that should actually be downloaded and compiled on the fly?


AFAIK iconv, zlib, hunspell and gettext. Unfortunately the zip file contains


JMarc said that gettext is not needed any more (there is no *getlib.lib in 
deps).

For iconv and hunspell one can find some CMakeLists.txt at github, not
ready for MSVC but usable as starting point. AFAIk zlib already ships
with cmake files.

Would it be an option to add tripped down iconv, hunspell and zlib sources
to lyx and to build them as static libraries like boost? Then the Windows
installer would only depend on ready-to-use binaries, maintained by other
projects.


a mixture of different kinds of dependencies: The ones I mentioned are
needed for compiling LyX, the others like python and ghostscript are for
building the installer or running LyX. In my initial answer I did not think
of the latter. I believe that we do not need to do much about these, since
you can always simply install the latest version of these tools.


  For example, do you think that Python and ghostscript should be
compiled from source, or do you think it suffices to just include up-to
-date Windows binaries?  Same question goes for other deps I think.
  Based on your feedback I can try to hack around with this a bit and
see what I can get working with the latest MSVC.


Very nice! Don't hesitate to ask if you've got any question, the worst thing
that can happen is that nobody knows (unlikely).


Georg

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Vincent van Ravesteijn]

Op 31-10-2015 om 14:44 schreef PhilipPirrip:

On 10/31/2015 09:27 AM, PhilipPirrip wrote:

Thanks, David. It did work with Qt 4.8.6
First thing I noticed, though, is that most icons are missing. Have to
investigate. I remember seeing a similar issue here on the list 
recently.


The errors reported in the message pane are of this kind
GuiApplication.cpp (635): Cannot load icon 
C:/LyX/lyx-install/Resources/images/thesaurus-entry.svgz please verify 
resource system!



Is there any special library, not mentioned in INSTALL.Win32 that 
needs to be copied somewhere? How can one force LyX to use png icons 
as a fallback?

Thnx



I'm already working on this issue.

The problem is that Qt 4.x cannot read svgz icon files where Qt 5.x can. 
There is some logic to fall back to png when the svgz file could not be 
read but this is poorly implemented and apparently untested.


Workaround would be to select classic icons in the preferences, or to 
change some occurences of "svgz,png" to "png" in the source code.


Vincent

Re: Compiling LyX on Windows with more recent Visual Studio versions

[PhilipPirrip]

On 10/31/2015 09:27 AM, PhilipPirrip wrote:

Thanks, David. It did work with Qt 4.8.6
First thing I noticed, though, is that most icons are missing. Have to
investigate. I remember seeing a similar issue here on the list recently.


The errors reported in the message pane are of this kind
GuiApplication.cpp (635): Cannot load icon 
C:/LyX/lyx-install/Resources/images/thesaurus-entry.svgz please verify 
resource system!



Is there any special library, not mentioned in INSTALL.Win32 that needs 
to be copied somewhere? How can one force LyX to use png icons as a 
fallback?

Thnx

Re: Compiling LyX on Windows with more recent Visual Studio versions

[PhilipPirrip]

Thanks, David. It did work with Qt 4.8.6
First thing I noticed, though, is that most icons are missing. Have to 
investigate. I remember seeing a similar issue here on the list recently.







On 10/31/2015 03:53 AM, David Hyde wrote:

I experienced this error as well when setting up my LyX build environment (Windows 
10 + MSVC 2010 + Qt 4.8.6).  The only insight I can provide is that initially, my 
cmake config wasn't an exact match to what was described in INSTALL.Win32.  That 
file was written for Qt < 5, so as part of getting everything to match 
INSTALL.Win32 and compile, I switched to Qt 4.8.6 rather than Qt 5.4 or 5.5.  I 
don't exactly recall if that switch was the silver bullet for this error, but I 
know I haven't been able to compile LyX yet using Qt 5.x on Windows.  Perhaps try 
compiling LyX with Qt 4.8.6 (keeping all other config the same), and see if that 
removes this error?  In which case there is possibly some issue with compiling 
with Qt 5.x on Windows...

Best regards,

David

Re: Compiling LyX on Windows with more recent Visual Studio versions

[David Hyde]

I experienced this error as well when setting up my LyX build environment 
(Windows 10 + MSVC 2010 + Qt 4.8.6).  The only insight I can provide is that 
initially, my cmake config wasn't an exact match to what was described in 
INSTALL.Win32.  That file was written for Qt < 5, so as part of getting 
everything to match INSTALL.Win32 and compile, I switched to Qt 4.8.6 rather 
than Qt 5.4 or 5.5.  I don't exactly recall if that switch was the silver 
bullet for this error, but I know I haven't been able to compile LyX yet using 
Qt 5.x on Windows.  Perhaps try compiling LyX with Qt 4.8.6 (keeping all other 
config the same), and see if that removes this error?  In which case there is 
possibly some issue with compiling with Qt 5.x on Windows...

Best regards,

David


From: lyx-devel@lists.lyx.org  on behalf of 
PhilipPirrip 
Sent: Friday, October 30, 2015 8:16 PM
To: lyx-devel@lists.lyx.org
Subject: Re: Compiling LyX on Windows with more recent Visual Studio versions

Hello!
I'm trying to compile LyX for Windows: WinXP VirtualBox, Visual Studio
2010, Qt 5.5, all by the instructions in INSTALL.Win32

No matter what I do in CMake config, the compilation ends with the
messages I give below, and I have no idea what's happening and how to
fix it.



24> -- Installing:
C:/LyX/lyx-install/Resources/doc/es/DocumentoTextoPostizo.txt
24> -- Installing:
C:/LyX/lyx-install/Resources/doc/attic/Changelog-UserGuide-LyX_22x.txt
24> -- Installing:
C:/LyX/lyx-install/Resources/doc/attic/Changelog-EmbeddedObjects-LyX_22x.txt
24> -- Installing:
C:/LyX/lyx-install/Resources/doc/attic/Changelog-Math-LyX_22.txt
24> -- Installing:
C:/LyX/lyx-install/Resources/doc/./SpecialParagraphShape.tex
24> -- Installing: C:/LyX/lyx-install/Resources/doc/LFUNs.lyx
24> CMake Error at src/cmake_install.cmake:32 (file):
24> file INSTALL cannot find "C:/LyX/lyx-build-windows/bin/Debug/LyX.exe".
24> Call Stack (most recent call first):
24> cmake_install.cmake:3975 (include)
24>
24>
24>
24>C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5):
error MSB3073: The command "setlocal
"C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P
cmake_install.cmake
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" exited with code 1.
24>
24>Build FAILED.
24>
24>Time Elapsed 00:00:47.16
== Build: 21 succeeded, 3 failed, 0 up-to-date, 0 skipped

Re: Compiling LyX on Windows with more recent Visual Studio versions

[PhilipPirrip]

Hello!
I'm trying to compile LyX for Windows: WinXP VirtualBox, Visual Studio 
2010, Qt 5.5, all by the instructions in INSTALL.Win32


No matter what I do in CMake config, the compilation ends with the 
messages I give below, and I have no idea what's happening and how to 
fix it.




24> -- Installing: 
C:/LyX/lyx-install/Resources/doc/es/DocumentoTextoPostizo.txt
24> -- Installing: 
C:/LyX/lyx-install/Resources/doc/attic/Changelog-UserGuide-LyX_22x.txt
24> -- Installing: 
C:/LyX/lyx-install/Resources/doc/attic/Changelog-EmbeddedObjects-LyX_22x.txt
24> -- Installing: 
C:/LyX/lyx-install/Resources/doc/attic/Changelog-Math-LyX_22.txt
24> -- Installing: 
C:/LyX/lyx-install/Resources/doc/./SpecialParagraphShape.tex

24> -- Installing: C:/LyX/lyx-install/Resources/doc/LFUNs.lyx
24> CMake Error at src/cmake_install.cmake:32 (file):
24> file INSTALL cannot find "C:/LyX/lyx-build-windows/bin/Debug/LyX.exe".
24> Call Stack (most recent call first):
24> cmake_install.cmake:3975 (include)
24>
24>
24>
24>C:\Program 
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5):

error MSB3073: The command "setlocal
"C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P 
cmake_install.cmake

if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" exited with code 1.
24>
24>Build FAILED.
24>
24>Time Elapsed 00:00:47.16
== Build: 21 succeeded, 3 failed, 0 up-to-date, 0 skipped

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Georg Baum]

David Hyde wrote:

> I'm interested in looking into this at least a bit (may become deterred
> if some dependency nightmare occurs!).  I've looked at the current MSVC
> dependencies that are in the archive on sourceforge.  Which of these
> are things that should actually be downloaded and compiled on the fly?

AFAIK iconv, zlib, hunspell and gettext. Unfortunately the zip file contains 
a mixture of different kinds of dependencies: The ones I mentioned are 
needed for compiling LyX, the others like python and ghostscript are for 
building the installer or running LyX. In my initial answer I did not think 
of the latter. I believe that we do not need to do much about these, since 
you can always simply install the latest version of these tools.

>  For example, do you think that Python and ghostscript should be
> compiled from source, or do you think it suffices to just include up-to
> -date Windows binaries?  Same question goes for other deps I think.
>  Based on your feedback I can try to hack around with this a bit and
> see what I can get working with the latest MSVC.

Very nice! Don't hesitate to ask if you've got any question, the worst thing 
that can happen is that nobody knows (unlikely).


Georg

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Jean-Marc Lasgouttes]

Le 14/10/2015 07:27, David Hyde a écrit :

Which of these
are things that should actually be downloaded and compiled on the fly?
  For example, do you think that Python and ghostscript should be
compiled from source, or do you think it suffices to just include up-to
-date Windows binaries?  Same question goes for other deps I think.


IMO, the things that need rebuilding are the libraries, not the helper 
programs. This rules out python and ghostscript.


JMarc

Re: Compiling LyX on Windows with more recent Visual Studio versions

[David Hyde]

Hi Georg,

Thanks for your reply!

> This is possible, but needs some work.
> 
> The current MSVC build instructions use some pre-compiled third party
> libraries. Of course these work only for exactly one MSVC version.
> Therefore 
> I would propose the following procedure instead of just replicating
> this 
> setup with a newer MSVC version:
> 
> Create a python or cmake script that downloads, unpacks and builds
> each 
> needed library. Add this script to the LyX git repo, and modify the
> windows 
> cmake setup to use it instead of the current binaries from
> sourceforge.


I'm interested in looking into this at least a bit (may become deterred
if some dependency nightmare occurs!).  I've looked at the current MSVC
dependencies that are in the archive on sourceforge.  Which of these
are things that should actually be downloaded and compiled on the fly? 
 For example, do you think that Python and ghostscript should be
compiled from source, or do you think it suffices to just include up-to
-date Windows binaries?  Same question goes for other deps I think. 
 Based on your feedback I can try to hack around with this a bit and
see what I can get working with the latest MSVC.

Thanks again!

David

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Georg Baum]

David Hyde wrote:

> Hi there,
> 
> 
> I'm interested in compiling LyX on Windows.  I've read through the
> INSTALL.Win32 file and was able to get LyX to compile from source using
> Visual C++ Express 2010, following the instructions in that file.

Great!

> I'm
> wondering though, is it possible (do people have experience, or know it
> doesn't work, etc.) to compile LyX using a more recent VS version (2013 or
> even 2015)?  VS2010 isn't supported very well anymore (it was hard to even
> find a download for VS2010), so being able to compile LyX on Windows using
> more modern toolchains would be very useful.

This is possible, but needs some work. Currently we are lacking a volunteer 
to do it. If you are interested (which would be much appreciated) we can 
help by answering any questions that might come up.

The current MSVC build instructions use some pre-compiled third party 
libraries. Of course these work only for exactly one MSVC version. Therefore 
I would propose the following procedure instead of just replicating this 
setup with a newer MSVC version:

Create a python or cmake script that downloads, unpacks and builds each 
needed library. Add this script to the LyX git repo, and modify the windows 
cmake setup to use it instead of the current binaries from sourceforge.

This is more initial work, but definitely worth it, because it has a very 
high probability that it works with future MSVC versions as well.


Georg

Re: Compiling LyX on Mac OS 10.7.5

[Stephan Witt]

Am 26.04.2013 um 18:46 schrieb Elmar Hinz :

> 
> On Fri, Apr 26, 2013 at 6:29 PM, Kornel Benko  wrote:
> Am Freitag, 26. April 2013 um 18:23:56, schrieb Elmar Hinz 
> 
> > Hello,
> >
> > IMHO there is no libc6 for mac. There is a
> >
> > /usr/lib/libSystem.dylib -> libSystem.B.dylib
> >
> > Elmar
> >
>  
> Is there also a appropriate devel *package*?
>  
> Kornel
> 
> I find a _debug* and a _profile* variant:
> 
> -r-xr-xr-x  1 root  wheel   475K 22 Mär  2012 /usr/lib/libSystem.B.dylib
> -r-xr-xr-x  1 root  wheel   475K 12 Apr  2012 /usr/lib/libSystem.B_debug.dylib
> -r-xr-xr-x  1 root  wheel   475K 12 Apr  2012 
> /usr/lib/libSystem.B_profile.dylib
> lrwxr-xr-x  1 root  wheel17B 22 Mär  2012 /usr/lib/libSystem.dylib -> 
> libSystem.B.dylib
> lrwxr-xr-x  1 root  wheel23B  2 Mär 13:51 /usr/lib/libSystem_debug.dylib 
> -> libSystem.B_debug.dylib
> lrwxr-xr-x  1 root  wheel25B  2 Mär 13:51 
> /usr/lib/libSystem_profile.dylib -> libSystem.B_profile.dylib
> 
> However I am new with Mac OS and still can't explain how it handles the stuff 
> we know as libc6 and libc6-dev.
> This gives start: http://docstore.mik.ua/orelly/unix3/mac/ch05_02.htm
> 
> For today I wanted to learn how to compile LyX and succeded largeley.
> 
> Next step is to bring in a patch to learn the workflow of the project.

Hi Elmar,

I'm building LyX on Mac for packaging with the script you can find in the 
source tree:
lyx/development/LyX-Mac-binary-release.sh

To use the Xcode tool for debugging I'm building LyX with cmake.

I'm building the Qt libs myself, too.

I've made a script to automate this process. 

The top level directory contains 
* the lyx sources in "lyx"
* the qt4 sources destilled from the source tarball
* the build directory for qt and lyx compilation files
* the install directory for the packaged results 

Perhaps you're interested in it, I'll attach it.

To use the debug libraries, you have to control the shared library loader.
You have to add DYLD_IMAGE_SUFFIX=_debug to your environment.

With Xcode you'll do that with "Edit scheme…" of your project.

Regards,
Stephan



mkbuild.sh
Description: Binary data

Re: Re: Re: Re: Compiling LyX on Mac OS 10.7.5

[Kornel Benko]

Am Freitag, 26. April 2013 um 18:46:17, schrieb Elmar Hinz 

> 
> I find a _debug* and a _profile* variant:

No, what you found are files, not packages.
Check please to which package belongs a specified file.
(I don't know how, sorry)

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Re: Compiling LyX on Mac OS 10.7.5

[Kornel Benko]

Am Freitag, 26. April 2013 um 18:31:11, schrieb Elmar Hinz 

> 
> Anyway, That doesn't bring in the missing Info.plist.
> 
> Question: Why is there no Info.plist in the source?

There is. It should be created from Info.plist.in at configure time.
That file itself is in the build-directory.
(See main-CMakeLists.txt:308)

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: Re: Re: Compiling LyX on Mac OS 10.7.5

[Elmar Hinz]

On Fri, Apr 26, 2013 at 6:29 PM, Kornel Benko  wrote:

> **
>
> Am Freitag, 26. April 2013 um 18:23:56, schrieb Elmar Hinz <
> t3el...@googlemail.com>
>
> > Hello,
>
> >
>
> > IMHO there is no libc6 for mac. There is a
>
> >
>
> > /usr/lib/libSystem.dylib -> libSystem.B.dylib
>
> >
>
> > Elmar
>
> >
>
>
>
> Is there also a appropriate devel *package*?
>
>
>
> Kornel
>

I find a _debug* and a _profile* variant:

-r-xr-xr-x  1 root  wheel   475K 22 Mär  2012 /usr/lib/libSystem.B.dylib
-r-xr-xr-x  1 root  wheel   475K 12 Apr  2012
/usr/lib/libSystem.B_debug.dylib
-r-xr-xr-x  1 root  wheel   475K 12 Apr  2012
/usr/lib/libSystem.B_profile.dylib
lrwxr-xr-x  1 root  wheel17B 22 Mär  2012 /usr/lib/libSystem.dylib ->
libSystem.B.dylib
lrwxr-xr-x  1 root  wheel23B  2 Mär 13:51
/usr/lib/libSystem_debug.dylib -> libSystem.B_debug.dylib
lrwxr-xr-x  1 root  wheel25B  2 Mär 13:51
/usr/lib/libSystem_profile.dylib -> libSystem.B_profile.dylib

However I am new with Mac OS and still can't explain how it handles the
stuff we know as libc6 and libc6-dev.
This gives start: http://docstore.mik.ua/orelly/unix3/mac/ch05_02.htm

For today I wanted to learn how to compile LyX and succeded largeley.

Next step is to bring in a patch to learn the workflow of the project.

Regards

Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: Compiling LyX on Mac OS 10.7.5

[Elmar Hinz]

> OK didn't follow the instruction:
> make LyX2.1 (to build the binary only)
> or
> make package (to get a mac bundle)
>

Anyway, That doesn't bring in the missing Info.plist.

Question: Why is there no Info.plist in the source?

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: Re: Re: Compiling LyX on Mac OS 10.7.5

[Kornel Benko]

Am Freitag, 26. April 2013 um 18:23:56, schrieb Elmar Hinz 

> Hello,
> 
> IMHO there is no libc6 for mac. There is a
> 
> /usr/lib/libSystem.dylib -> libSystem.B.dylib
> 
> Elmar
> 

Is there also a appropriate devel *package*?

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Re: Compiling LyX on Mac OS 10.7.5

[Elmar Hinz]

> or prefered:
>
> b.) Install the devel package for libc6 (on ubuntu libc6-dev)
>
>
>
> > Elmar
>
> >
>
> Kornel
>

Hello,

IMHO there is no libc6 for mac. There is a

/usr/lib/libSystem.dylib -> libSystem.B.dylib

Elmar

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: Compiling LyX on Mac OS 10.7.5

[Elmar Hinz]

> The second one seems to be cased by the first one.
>

OK didn't follow the instruction:

make LyX2.1 (to build the binary only)
or
make package (to get a mac bundle)

Elmar

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: Re: Compiling LyX on Mac OS 10.7.5

[Kornel Benko]

Am Freitag, 26. April 2013 um 16:44:22, schrieb Elmar Hinz 

> here is the command line I use (with cmake, out of source build) in a build
> directory (different from LyX main directory). It works with QT installed
> via the QT installer package (not from source):
> 
> >
> > cmake -DLYX_BUNDLE=ON -DLYX_COCOA=ON -DLYX_INSTALL=ON -DLYX_RELEASE=OFF
> > -DLYX_DEBUG=ON PATH_TO_LYX_MAIN_DIRECTORY
> >
> > and then
> >
> > make LyX2.1 (to build the binary only)
> > or
> > make package (to get a mac bundle)
> >
> > Best,
> > Benjamin
> >
> 
> Hello Benjamin,
> 
> I did:
> 
> > brew install cmake
> > cmake -DLYX_BUNDLE=ON -DLYX_COCOA=ON -DLYX_INSTALL=ON -DLYX_RELEASE=OFF
> -DLYX_DEBUG=ON . # <= DOT, current dir
> 
> It is missing "libintl.h". Sie issue is mentioned here:
> http://www.gnu.org/software/gnulib/manual/html_node/libintl_002eh.html
> 
> It tried to fix it with  "> brew install gettext" unforutnatly without
> success.
> 
> Any other workaround?

Sure.
a.) You could use the lyx-provided libintl with
cmake ... -DLYX_EXTERNAL_LIBINTL=OFF ...

or prefered:
b.) Install the devel package for libc6 (on ubuntu libc6-dev)

> Elmar
> 
Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Compiling LyX on Mac OS 10.7.5

[Elmar Hinz]

Summary:

* QT 4.8.4 installed via the QT installer package (not from source)
* brew install cmake
* cmake -DLYX_NLS=OFF -DLYX_BUNDLE=ON -DLYX_COCOA=ON -DLYX_INSTALL=ON
-DLYX_RELEASE=OFF -DLYX_DEBUG=ON -DLYX_EXTERNAL_LIBINTL=OFF .
* make
* make install

Errors from cmake:

CMake Error: Target LyX Info.plist template
"/Users/elmar/lyx/build/src/../Info.plist" could not be found.

Errors from make install:

-- fixup_bundle
--   app='/Users/elmar/lyx/LyX/LyX.app'
--   libs=''
--   dirs=''
-- warning: *NOT* handled - .app directory case...
CMake Error at /usr/local/Cellar/cmake/
2.8.10.2/share/cmake/Modules/BundleUtilities.cmake:668 (message):
  error: fixup_bundle: not a valid bundle

The second one seems to be cased by the first one.

The application  LyX/LyX.app/Contents/MacOS/LyX is running an looks fine.

Regards

Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: Compiling LyX on Mac OS 10.7.5

[Elmar Hinz]

here is the command line I use (with cmake, out of source build) in a build
directory (different from LyX main directory). It works with QT installed
via the QT installer package (not from source):

>
> cmake -DLYX_BUNDLE=ON -DLYX_COCOA=ON -DLYX_INSTALL=ON -DLYX_RELEASE=OFF
> -DLYX_DEBUG=ON PATH_TO_LYX_MAIN_DIRECTORY
>
> and then
>
> make LyX2.1 (to build the binary only)
> or
> make package (to get a mac bundle)
>
> Best,
> Benjamin
>

Hello Benjamin,

I did:

> brew install cmake
> cmake -DLYX_BUNDLE=ON -DLYX_COCOA=ON -DLYX_INSTALL=ON -DLYX_RELEASE=OFF
-DLYX_DEBUG=ON . # <= DOT, current dir

It is missing "libintl.h". Sie issue is mentioned here:
http://www.gnu.org/software/gnulib/manual/html_node/libintl_002eh.html

It tried to fix it with  "> brew install gettext" unforutnatly without
success.

Any other workaround?

Elmar


-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: Compiling LyX on Mac OS 10.7.5

[Benjamin Piwowarski]

Hi,

here is the command line I use (with cmake, out of source build) in a build 
directory (different from LyX main directory). It works with QT installed via 
the QT installer package (not from source):

cmake -DLYX_BUNDLE=ON -DLYX_COCOA=ON -DLYX_INSTALL=ON -DLYX_RELEASE=OFF 
-DLYX_DEBUG=ON PATH_TO_LYX_MAIN_DIRECTORY

and then

make LyX2.1 (to build the binary only)
or
make package (to get a mac bundle)

Best,
Benjamin

On Apr 26, 2013, at 13:39 , Elmar Hinz  wrote:

> Hello,
> 
> before diving into coding I need to learn how to compile LyX.
> The documentation for Mac is a little out-of-date, so I try to
> find my own way.
> 
> I compiled Qt4 and LyX. The first build did break immediately upon start.   
> Currently I try to compile both with 
> 
> export CPPFLAGS="-arch i386"
> export LDFLAGS="-arch i386" 
> 
> This will take some time. Any further suggestions required for a contemporary 
> Mac?
> 
> Regards
> 
> Elmar
> 
> -- 
> Elmar Hinz
> Freiherr-vom-Stein-Str. 1
> 33014 Bad Driburg
> 
> TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
> personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m
> 

Re: Compiling LyX with -std=gnu++1

[André Pönitz]

On Mon, Nov 21, 2011 at 12:02:15AM +0100, Lars Gullik Bjønnes wrote:
> Systemcall.cpp:337:65: error: inconsistent user-defined literal suffixes 
> ‘__FILE__’ and ‘QTOSTRING’ in string literal
> Systemcall.cpp:337:65: error: unable to find user-defined string literal 
> operator ‘operator"" __FILE__’
> 
> This seems to be our own problem.
> Unless it is something we inherit from Qt.
> Ahh nice... it is Qt.

Indeed. The error istriggered by

  #define QTOSTRING_HELPER(s) #s
  #define QTOSTRING(s) QTOSTRING_HELPER(s)
  #define QLOCATION "\0"__FILE__":"QTOSTRING(__LINE__)

> And the wonderfull non-c++ parts of Qt.

The preprocessor is part of C++ (both 98/03 and 11), how that can be
dubbed "non-c++" is beyond me.

The first two lines represent the canonical way to stringify expanded
values using the C++ preprocessor.  The third line is valid C++ in the
1998 and 2003 versions of the Standard.

Unfortunately, the 2011 version of the Standard introduces "user
defined literals" which are - as shown by this example - source
incompatible, i.e. previously valid code is now invalid.

Blaming library code that has been around for a quite a while for not
anticipating such changes seems odd, especially if previous versions
of gcc happily accepted that code in "C++0x" mode.

Andre'

Re: Compiling LyX with -std=gnu++1

[Abdelrazak Younes]

On 22/11/2011 22:09, Abdelrazak Younes wrote:

On 21/11/2011 23:40, Vincent van Ravesteijn wrote:



>
> And won't have, as long as the core steers the gui [ 1/2 ;-) ]
>
> Andre'

And the core will be steering the GUI as long as we can't use qt 
signals in the core.




And we won't use Qt signals in the core as long as nobody makes the 
effort to use it in the core.


Just to be clearer, we decided 2 years ago, that QtCore is now allowed 
in src/ wherever needed. Qt signals is obviously needed there, 
Buffer::changed() signal being the main use case.


As far the core steering the gui, we are not so far from doing the 
opposite. We just need to cleanup/reorganise a bit more the dispatch 
machinery.


Abdel.

Re: Compiling LyX with -std=gnu++1

[Abdelrazak Younes]

On 21/11/2011 23:40, Vincent van Ravesteijn wrote:



>
> And won't have, as long as the core steers the gui [ 1/2 ;-) ]
>
> Andre'

And the core will be steering the GUI as long as we can't use qt 
signals in the core.




And we won't use Qt signals in the core as long as nobody makes the 
effort to use it in the core.


Abdel.

Re: Compiling LyX with -std=gnu++1

[Vincent van Ravesteijn]

>
> And won't have, as long as the core steers the gui [ 1/2 ;-) ]
>
> Andre'

And the core will be steering the GUI as long as we can't use qt signals in
the core.

Vincent

Re: Compiling LyX with -std=gnu++1

[André Pönitz]

On Mon, Nov 21, 2011 at 10:44:04PM +0100, Peter Kümmel wrote:
> On 21.11.2011 20:50, André Pönitz wrote:
> >On Mon, Nov 21, 2011 at 10:11:11AM +0100, Lars Gullik Bjønnes wrote:
> >>Peter Kümmel  writes:
> >>
> >>| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:
> >>>
> This is boost warning if I am not mistaken.
> I guess the boost people can trivially change this to std::unique_ptr.
> 
> Systemcall.cpp: In constructor 
> ‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
> string&)’:
> 
> This seems to be our own problem.
> Unless it is something we inherit from Qt.
> Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.
> >>>
> >>| The SIGNAL/SLOT macro. In Qt5 there will be a template based connect 
> >>without
> >>| any macros (but mocing will remain).
> >>
> >>That is good news.
> >
> >Which, lacking run-time introspection in the core language, will only
> >work for connections with defined targets at compile time, i.e. no
> >simple "service discovery" through plugins, or over the network etc.
> 
> we not even have shared libraries.

And won't have, as long as the core steers the gui [ 1/2 ;-) ]

Andre'

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 20:50, André Pönitz wrote:

On Mon, Nov 21, 2011 at 10:11:11AM +0100, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:



This is boost warning if I am not mistaken.
I guess the boost people can trivially change this to std::unique_ptr.

Systemcall.cpp: In constructor 
‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
string&)’:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.



| The SIGNAL/SLOT macro. In Qt5 there will be a template based connect without
| any macros (but mocing will remain).

That is good news.


Which, lacking run-time introspection in the core language, will only
work for connections with defined targets at compile time, i.e. no
simple "service discovery" through plugins, or over the network etc.


we not even have shared libraries.



But sure, LyX's signal/slot use would be covered.

Andre'

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 10:10, Lars Gullik Bjønnes wrote:

Peter Kümmel  writes:

| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.

Oh well... I'll wait half a year before repeating that test. Hopefully a
new version of Qt will have been released by then.




| There will be 4.8. But updating to 5.0 is maybe superfluous: much
| trouble but no benefit, not much will happen on the QWidget side.

I think Qt might need to change a bit for the new C++11 compilers that
will be released during the next years. Not to use the new C++11


Most things are trivial. They only haven't tested it with 4.7.


features, but to at least compile with the new compilers.
(And the errors that I see with lyx and gnu++11 can just as well be gcc
problems as Qt problems as of now.)

Re: Compiling LyX with -std=gnu++1

[André Pönitz]

On Mon, Nov 21, 2011 at 10:11:11AM +0100, Lars Gullik Bjønnes wrote:
> Peter Kümmel  writes:
> 
> | On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:
> >
> >> This is boost warning if I am not mistaken.
> >> I guess the boost people can trivially change this to std::unique_ptr.
> >>
> >> Systemcall.cpp: In constructor 
> >> ‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
> >> string&)’:
> >>
> >> This seems to be our own problem.
> >> Unless it is something we inherit from Qt.
> >> Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.
> >
> | The SIGNAL/SLOT macro. In Qt5 there will be a template based connect without
> | any macros (but mocing will remain).
> 
> That is good news.

Which, lacking run-time introspection in the core language, will only
work for connections with defined targets at compile time, i.e. no
simple "service discovery" through plugins, or over the network etc.

But sure, LyX's signal/slot use would be covered.

Andre'

Re: Compiling LyX with -std=gnu++1

[Lars Gullik Bjønnes]

Peter Kümmel  writes:

| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:
>> This seems to be our own problem.
>> Unless it is something we inherit from Qt.
>> Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.
>>
>> Oh well... I'll wait half a year before repeating that test. Hopefully a
>> new version of Qt will have been released by then.
>>
>
| There will be 4.8. But updating to 5.0 is maybe superfluous: much
| trouble but no benefit, not much will happen on the QWidget side.

I think Qt might need to change a bit for the new C++11 compilers that
will be released during the next years. Not to use the new C++11
features, but to at least compile with the new compilers.
(And the errors that I see with lyx and gnu++11 can just as well be gcc
problems as Qt problems as of now.)

-- 
   Lgb

Re: Compiling LyX with -std=gnu++1

[Lars Gullik Bjønnes]

Peter Kümmel  writes:

| On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:
>
>> This is boost warning if I am not mistaken.
>> I guess the boost people can trivially change this to std::unique_ptr.
>>
>> Systemcall.cpp: In constructor 
>> ‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
>> string&)’:
>>
>> This seems to be our own problem.
>> Unless it is something we inherit from Qt.
>> Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.
>
| The SIGNAL/SLOT macro. In Qt5 there will be a template based connect without
| any macros (but mocing will remain).

That is good news.

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:


This is boost warning if I am not mistaken.
I guess the boost people can trivially change this to std::unique_ptr.

Systemcall.cpp: In constructor 
‘lyx::support::SystemcallPrivate::SystemcallPrivate(const string&, const 
string&)’:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.


The SIGNAL/SLOT macro. In Qt5 there will be a template based connect without
any macros (but mocing will remain).



Oh well... I'll wait half a year before repeating that test. Hopefully a
new version of Qt will have been released by then.

Re: Compiling LyX with -std=gnu++1

[Peter Kümmel]

On 21.11.2011 00:02, Lars Gullik Bjønnes wrote:

This seems to be our own problem.
Unless it is something we inherit from Qt.
Ahh nice... it is Qt. And the wonderfull non-c++ parts of Qt.

Oh well... I'll wait half a year before repeating that test. Hopefully a
new version of Qt will have been released by then.



There will be 4.8. But updating to 5.0 is maybe superfluous: much
trouble but no benefit, not much will happen on the QWidget side.

Peter

Re: Re: Re: Compiling LyX under FreeBSD

[rainel]

> Maybe you need

> 

>   ./configure --with-libiconv-prefix=/usr/local

> 

> given that you have installed libiconv?



All right, it's no bug, only my lack of knowledge. I've managed to install a 
whole lot of dependecies, then compile with gmake in about 15 minutes. I 
thought configure would warn about missing packages. Thanks for the help and 
sorry for the false warning.



Rainel





 - Indamail [x] -



 Indamail a nagyoknak!

 Nagy láda a leveleknek, óriáscsatolmány a barátoknak!

 Indamailezz Te is!

 

Re: Re: Compiling LyX under FreeBSD

[Yokota K.]

> docstream.cpp:19:19: error: iconv.h: No such file or directory

Maybe you need

  ./configure --with-libiconv-prefix=/usr/local

given that you have installed libiconv?

Koji

Re: Re: Compiling LyX under FreeBSD

[rainel]

> Which 'make' is that? Not GNU make, I guess. I'd be will to work on

> having our make infrastructure work in these case, but I do not know how

> difficult this is. Typically, for moc files we use rules like this one

>   %_moc.cpp: %.h

>$(MOC4) -o $@ $<

> which creates foo.moc.cpp from foo.h. This use of % is GNU-only AFAIK.



I did some searching and you're right, BSD has it's own make, and conforming 
both BSD and GNU make looks PITA. But BSD contains a GNU make called gmake, so 
you don't have to mess with paths. I did a clean/distclean/gmake and here's a 
new error:





 g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I../../boost -DQT_NO_STL 
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/PCBSD/local/include/qt4 
-I/usr/PCBSD/local/include/qt4/QtCore -D_THREAD_SAFE -O2 -MT debug.lo -MD -MP 
-MF .deps/debug.Tpo -c debug.cpp -o debug.o 

mv -f .deps/debug.Tpo .deps/debug.Plo   


/bin/sh ../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..   -I./.. -I../../boost -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_SHARED 
-I/usr/PCBSD/local/include/qt4 -I/usr/PCBSD/local/include/qt4/QtCore   
-D_THREAD_SAFE  -O2 -MT docstream.lo -MD -MP -MF .deps/docstream.Tpo -c -o 
docstream.lo docstream.cpp  
 

 g++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -I../../boost -DQT_NO_STL 
-DQT_NO_KEYWORDS -DQT_SHARED -I/usr/PCBSD/local/include/qt4 
-I/usr/PCBSD/local/include/qt4/QtCore -D_THREAD_SAFE -O2 -MT docstream.lo -MD 
-MP -MF .deps/docstream.Tpo -c docstream.cpp -o docstream.o 

docstream.cpp:19:19: error: iconv.h: No such file or directory  


docstream.cpp:250: error: 'iconv_t' has not been declared   


docstream.cpp:278: error: 'iconv_t' does not name a type


docstream.cpp:279: error: 'iconv_t' does not name a type


docstream.cpp: In constructor 
'::iconv_codecvt_facet::iconv_codecvt_facet(const std::string&, 
std::_Ios_Openmode, size_t)':

docstream.cpp:46: error: 'in_cd_' was not declared in this scope


docstream.cpp:46: error: 'iconv_open' was not declared in this scope


docstream.cpp:47: error: 'iconv_t' was not declared in this scope   


docstream.cpp:54: error: 'in_cd_' was not declared in this scope


docstream.cpp:54: error: 'iconv_t' was not declared in this scope   


docstream.cpp:56: error: 'out_cd_' was not declared in this scope   


docstream.cpp:56: error: 'iconv_open' was not declared in this scope


docstream.cpp:57: error: 'iconv_t' was not declared in this scope   


docstream.cpp:64: error: 'out_cd_' was not declared in this scope   


docstream.cpp:64: error: 'iconv_t' was not declared in this scope   


docstream.cpp: In destructor 
'virtual::iconv_codecvt_facet::~iconv_codecvt_facet()':
   

docstream.cpp:69: error: 'in_cd_' was not declared in this scope


docstream.cpp:69: error: 'iconv_t' was not declared in this scope   


docstream.cpp:70: error: 'iconv_close' was not declared in this scope

docstream.cpp:75: error: 'out_cd_' was not declared in this scope

docstream.cpp:75: error: 'iconv_t' was not declared in this scope

docstream.cpp:76: error: 'iconv_close' was not declared in this scope

docstream.cpp: In member function 'virtual 
std::codecvt_base::result::iconv_codecvt_facet::do_out(__mbstate_t&, 
const unsigned int*, const unsigned int*, const unsigned int*&, char*, char*, 
char*&) const':

docstream.cpp:117: error: 'out_cd_' was not declared in this scope

docstream.cpp: In member function 'virtual 
std::codecvt_base::result::iconv_codecvt_facet::do_in(__mbstate_t&, 
const char*, const char*, const char*&, unsigned int*, unsigned int*, unsigned 
int*&) const':

docstream.cpp:178: error: 'in

Re: Compiling LyX under FreeBSD

[Jean-Marc Lasgouttes]

"rainel"  writes:

> Hello all!
>
> I'm experimenting with PC-BSD, and looks like LyX 1.6.4 won't compile. It's a 
> PC-BSD 7.1.1, based on FreeBSD 7.2, 64 bit, running on a Core 2 Duo. 
> Configure says everything's ok, then make errors out. Here are the last few 
> lines of time make:

Which 'make' is that? Not GNU make, I guess. I'd be will to work on
having our make infrastructure work in these case, but I do not know how
difficult this is. Typically, for moc files we use rules like this one
  %_moc.cpp: %.h
$(MOC4) -o $@ $<
which creates foo.moc.cpp from foo.h. This use of % is GNU-only AFAIK.

I see that PC-BSD only has a port for 1.5.7. This port might be a good
starting point for you. Alternatively, you can install GNU make and run
configure with ``MAKE=/path/to/gnu/make'' as extra argument.

JMarc

RE: Compiling LyX under FreeBSD

[Vincent van Ravesteijn - TNW]

 
>I'm experimenting with PC-BSD, and looks like LyX 1.6.4 won't compile.
>
> [...]
>
>make: don't know how to make SignalSlotPrivate_moc.cpp. Stop
>

Either do a make clean, autogen, autoconf or manually remove this file.
The files *_moc.cpp are auto-generated (by qt) and were renamed to
moc_*.cpp some time ago.

Vincent

Re: compiling LyX

[Andre Poenitz]

On Mon, Apr 21, 2008 at 10:24:34AM +0200, Pavel Sanda wrote:
> > So bigger compilation units are better, right? Any tricks around this?
> 
> Andre, do you have the ratio for monolithic builds?

No. But I can create a few numbers manually... hang on.

Revision 21692: non-monolithic
Total: compiled: 17310566  real: 150056  ratio: 115
graphics:  compiled:   669162  real:   2617  ratio: 255
frontends/qt4: compiled:  4386626  real:  27020  ratio: 162
support:   compiled:  1432410  real:   9600  ratio: 149
mathed:compiled:  2357984  real:  19339  ratio: 121
insets:compiled:  2415915  real:  21566  ratio: 112
src/*.cpp: compiled:  4318608  real:  54814  ratio:  78

Revision 24415: non-monolithic
frontends/qt4: compiled:  4296379  real:  34614  ratio: 124
insets:compiled:  2535206  real:  22128  ratio: 114 

Revision 24415: monolithic
frontends/qt4: compiled:   209600  real:  34614  ratio:   6
insets:compiled:   122255  real:  22128  ratio:   5

So:

1. Monolithic builds reduce the ratio by a factor(!) of 20(!).
This does not translate directly into compilation times (due
to non-linear optimization effects) and even less to build times
(due to the extra time spend by linking and the make architecture),
but is nevertheless significant 

2. The effort spend to 'de-boostify' the frontend brought an
improvement of roughly 25%. It's still bad ...

Andre'

Re: compiling LyX

[Andre Poenitz]

On Mon, Apr 21, 2008 at 11:20:17AM +0300, Martin Vermeer wrote:
> On Sat, 19 Apr 2008 21:01:44 +0200
> Andre Poenitz <[EMAIL PROTECTED]> wrote:
> 
> ...
> 
> > > (I.e., how does it look as total lines vs. unique lines)?
> > 
> > I don't understand the question. Our ~500 lines .cpp files typically
> > yield a ~5 lines compilation unit after the preprocessor expanded
> > all #includes. The resulting lines are more or less unique, but of
> > course most of the 49500 lines overhead will also be part of the next
> > compilation unit produced from the next .cpp file. Is that answering the
> > question?
> > 
> > Andre'
> 
> Depressively, yes. 
> 
> So bigger compilation units are better, right?

Well, it certainly does not hurt to put two or three classes that
"intrinsically belong together" in the same file. I did that in
a few cases, but do not really want use extend that "solution"
excessively.

And, this scales linearily only without optimization. With
optimization switched on the compiler seems to play non-linear
optimization games...

> Any tricks around this?

The configure options

  --enable-monolithic-boost
  Use monolithic boost compilations
  --enable-monolithic-client
  Use monolithic client compilations
  --enable-monolithic-insets
  Use monolithic insets compilations
  --enable-monolithic-mathed
  Use monolithic mathed compilations
  --enable-monolithic-core
  Use monolithic core files compilations
  --enable-monolithic-tex2lyx
  Use monolithic tex2lyx compilations
  --enable-monolithic-frontend-qt4
  Use monolithic compilation of the Qt 4...

create a single big compilation unit out of the respective
subdirectories. This compiles much faster than all files one-by-one, but
of course, it will recompile the big unit as soon as a single line
has changed.

Other than that there are only politically incorrect solutions...

A hand-crafted string class e.g. would pull in less then 1000 lines
instead of std::string's 18700. Assuming that right now almost all of
the 400 compilation units use it that could save around 6 million lines,
or around 40% of the current work.

Andre'

Re: compiling LyX

[Abdelrazak Younes]

Martin Vermeer wrote:

On Sat, 19 Apr 2008 21:01:44 +0200
Andre Poenitz <[EMAIL PROTECTED]> wrote:

...

  

(I.e., how does it look as total lines vs. unique lines)?
  

I don't understand the question. Our ~500 lines .cpp files typically
yield a ~5 lines compilation unit after the preprocessor expanded
all #includes. The resulting lines are more or less unique, but of
course most of the 49500 lines overhead will also be part of the next
compilation unit produced from the next .cpp file. Is that answering the
question?

Andre'



Depressively, yes. 


So bigger compilation units are better, right? Any tricks around this?
  
If you want to compile and only compile (as opposed to debug, etc), the 
merge option of CMake brings a lot of speed (3x) by merging all cpp file 
in a library into one, very impressive.


Abdel.

Re: compiling LyX

[Pavel Sanda]

> So bigger compilation units are better, right? Any tricks around this?

Andre, do you have the ratio for monolithic builds?

pavel

Re: compiling LyX

[Martin Vermeer]

On Sat, 19 Apr 2008 21:01:44 +0200
Andre Poenitz <[EMAIL PROTECTED]> wrote:

...

> > (I.e., how does it look as total lines vs. unique lines)?
> 
> I don't understand the question. Our ~500 lines .cpp files typically
> yield a ~5 lines compilation unit after the preprocessor expanded
> all #includes. The resulting lines are more or less unique, but of
> course most of the 49500 lines overhead will also be part of the next
> compilation unit produced from the next .cpp file. Is that answering the
> question?
> 
> Andre'

Depressively, yes. 

So bigger compilation units are better, right? Any tricks around this?

- Martin

Re: compiling LyX

[Andre Poenitz]

On Sat, Apr 19, 2008 at 06:25:05PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> Just as a side note: For the first time we have a ratio of less then
>> 100 when comparing "total compiled lines of code" vs "our code":
>>
>>  Total: compiled: 16378361  real: 164656  ratio: 99
>>
>> We had about 24630737 lines half a year ago
>>   
> What was the ratio half a year ago? I mean the real number of loc...
> Or do you have these number for 1.5, that would be a fair comparison.

Well, I could sync back and check, but that's quite an effort...
As a rough estimate we still have more or less the same line count
as we had at the beginning of the 1.6 cycle, give or take 1 lines.
(New features, new code, removal of some old code...)

The first 'ratio' I have a record of is 120 on Nov 26. As a rough
estimate I'd say 140 or so at the beginning of 1.6.

Andre'

Re: compiling LyX

[Andre Poenitz]

On Sat, Apr 19, 2008 at 04:22:23PM +0300, Martin Vermeer wrote:
> On Sat, Apr 19, 2008 at 09:27:31AM +0200, Andre Poenitz wrote:
> > 
> > Just as a side note: For the first time we have a ratio of less then
> > 100 when comparing "total compiled lines of code" vs "our code":
> > 
> >  Total: compiled: 16378361  real: 164656  ratio: 99
> > 
> > We had about 24630737 lines half a year ago
> > 
> > Andre'
> 
> Where are those lines? Boost? Qt?

>From all the includes.

Have a look at development/tools/numbers to get a rough idea what costs
are assocated with certain #includes.

> And where does the reduction come from?

Mostly by throwing out boost stuff, removing the controller classes and 
using more Qt in the frontend.

> Did we repeatedly compile the same lines?

We still do that. 

> (I.e., how does it look as total lines vs. unique lines)?

I don't understand the question. Our ~500 lines .cpp files typically
yield a ~5 lines compilation unit after the preprocessor expanded
all #includes. The resulting lines are more or less unique, but of
course most of the 49500 lines overhead will also be part of the next
compilation unit produced from the next .cpp file. Is that answering the
question?

Andre'

Re: compiling LyX

[Abdelrazak Younes]

Andre Poenitz wrote:

Just as a side note: For the first time we have a ratio of less then
100 when comparing "total compiled lines of code" vs "our code":

 Total: compiled: 16378361  real: 164656  ratio: 99

We had about 24630737 lines half a year ago
  

What was the ratio half a year ago? I mean the real number of loc...
Or do you have these number for 1.5, that would be a fair comparison.

Abdel.

Re: compiling LyX

[Martin Vermeer]

On Sat, Apr 19, 2008 at 09:27:31AM +0200, Andre Poenitz wrote:
> 
> Just as a side note: For the first time we have a ratio of less then
> 100 when comparing "total compiled lines of code" vs "our code":
> 
>  Total: compiled: 16378361  real: 164656  ratio: 99
> 
> We had about 24630737 lines half a year ago
> 
> Andre'

Where are those lines? Boost? Qt?
And where does the reduction come from? Did we repeatedly compile the same 
lines? (I.e., how does it look as total lines vs. unique lines)?

- Martin

Re: Compiling LyX 1.4.x on opensuse 10.2

[Stephan Witt]

Jean-Marc Lasgouttes wrote:
>> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes:
> 
> Stephan> Dear JMarc, after succesfully building an 1.5.0svn checkout
> Stephan> on the OpenSUSE 10.2 platform I tried to build the current
> Stephan> 1.4.4 stable release because the distribution is shipped with
> Stephan> 1.4.2. But I failed miserably and I didn't find any hint or
> Stephan> cook-book like recipe what to do.
> 
> LyX 1.4 does not grok qt4, like LyX 1.5 snubs qt3. Do you have the qt3
> development headers installed? You should point to them with
> --with-qt-dir=/foo/bar

Thank you, I did it already, but before installing package qt3-devel.
I didn't realize that the headers I found manually are for Qt4 only and
building LyX without the qt3-devel package cannot succeed. After
installing the development-package I have to point LyX to /usr/lib/qt3.

Now I have a working configure and compile (again). I didn't understand
the INSTALL file apparently.

After all it's easy and the problem is sitting in front of the desktop.
Thank you again.

Stephan

Re: Compiling LyX 1.4.x on opensuse 10.2

[Jean-Marc Lasgouttes]

> "Stephan" == Stephan Witt <[EMAIL PROTECTED]> writes:

Stephan> Dear JMarc, after succesfully building an 1.5.0svn checkout
Stephan> on the OpenSUSE 10.2 platform I tried to build the current
Stephan> 1.4.4 stable release because the distribution is shipped with
Stephan> 1.4.2. But I failed miserably and I didn't find any hint or
Stephan> cook-book like recipe what to do.

LyX 1.4 does not grok qt4, like LyX 1.5 snubs qt3. Do you have the qt3
development headers installed? You should point to them with
--with-qt-dir=/foo/bar

JMarc

Re: Compiling LyX 1.4.x on opensuse 10.2

[Richard Heck]

I'd check that you're finding the QT3 libraries. 1.5.svn uses QT4.

Stephan Witt wrote:
> Dear JMarc,
>
> after succesfully building an 1.5.0svn checkout on the OpenSUSE 10.2
> platform I tried to build the current 1.4.4 stable release because the
> distribution is shipped with 1.4.2. But I failed miserably and I didn't
> find any hint or cook-book like recipe what to do.
>
> Here's what I did:
>
> % svn checkout \
>  svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_4_X lyx-1.4.4
>
> Then I did autogen.sh and created my build tree
>
> % (cd lyx-1.4.4 ; ./autogen.sh)
> % mkdir qt-1.4.4
> % (cd qt-1.4.4 ; ../lyx-1.4.4/configure --with-frontend=qt)
>
> There was some output as usual but the end was not happy :(
>
> ...
> checking for IceConnectionNumber in -lICE... yes
> checking for moc2... not found
> checking for moc... /usr/bin/moc
> checking for uic... /usr/bin/uic
> checking whether uic supports -nounload... no
> checking for Qt library name... failed
> checking whether the Qt library is multi-threaded... no
> checking whether NLS is requested... yes
> checking for msgfmt... /usr/bin/msgfmt
> ...
> Configuration
>   Host type:  i686-pc-linux-gnu
>   Special build flags:assertions pch concept-checks
> stdlib-debug warnings  use-ispell
>   C   Compiler:   gcc
>   C   Compiler LyX flags:
>   C   Compiler flags: -Wextra -Wall-g -O
>   C++ Compiler:   g++ (4.1.2)
>   C++ Compiler LyX flags:  -fno-exceptions
>   C++ Compiler flags: -Wextra -Wall-g -O
>   Linker flags:
>   Linker user flags:
>   Qt Frontend:
>   Qt version:
>   Packaging:  posix
>   LyX binary dir: /usr/local/bin
>   LyX files dir:  /usr/local/share/lyx
>
>  The following problems have been detected by configure.
>  Please check the messages below before running 'make'.
>  (see the section 'Problems' in the INSTALL file)
>
> %
>
> The config.log contains the following:
>
> Using built-in specs.
> Target: i586-suse-linux
> Configured with: ../configure --enable-threads=posix --prefix=/usr
> --with-local-prefix=/usr/local
> --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib
> --libexecdir=/usr/lib --enable
> -languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release
> --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp
> --disable-libssp --disable-libgcj --with-slibdir=/lib --with-sys
> tem-zlib --enable-shared --enable-__cxa_atexit
> --enable-libstdcxx-allocator=new --program-suffix=-
> 4.1 --enable-version-specific-runtime-libs --without-system-libunwind
> --with-cpu=generic --host=i586-suse-linux
> Thread model: posix
> gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
> ...
> configure:26749: checking for Qt library name
> configure:26799: g++ -o conftest -g -O   -Wextra -Wall conftest.cpp
>  -lSM -lICE -lc -lm   -lX1
> 1  -lqt-mt >&5
> conftest.cpp:40:22: error: qglobal.h: No such file or directory
> conftest.cpp:41:22: error: qstring.h: No such file or directory
> conftest.cpp:49: error: stray '\' in program
> conftest.cpp:49: error: stray '\' in program
> conftest.cpp: In function 'int main()':
> conftest.cpp:47: error: 'QString' was not declared in this scope
> conftest.cpp:47: error: expected `;' before 's'
> conftest.cpp:49: error: 'break_me_' was not declared in this scope
> configure:26805: $? = 1
> configure: failed program was:
>
> So it doesn't find "my" Qt includes. When trying to pass some include
> directories it fails to detect the libraries. Where is the mistake?
> And why is it working with 1.5.0?
>
> How do you built your 1.4.4 binaries?
>
> Regards, Stephan
>
> ---
>   


-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Re: Compiling LyX 1.5 with scons

[Enrico Forestieri]

On Fri, Sep 15, 2006 at 09:27:36PM -0500, Bo Peng wrote:

> >  I don't think
> > that scons let you choose these locations independently of each other,
> > though. Bo?
> 
> It is not difficult at all to add these options, but will lyx know
> where to find these files?

I think so. Autotools let you fine tune the location of those dirs.
Here is an excerpt from "configure --help":

--
Installation directories:
  --prefix=PREFIX install architecture-independent files in PREFIX
  [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
  [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR   user executables [EPREFIX/bin]
  --sbindir=DIR  system admin executables [EPREFIX/sbin]
  --libexecdir=DIR   program executables [EPREFIX/libexec]
  --datadir=DIR  read-only architecture-independent data [PREFIX/share]
  --sysconfdir=DIR   read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIRmodifiable single-machine data [PREFIX/var]
  --libdir=DIR   object code libraries [EPREFIX/lib]
  --includedir=DIR   C header files [PREFIX/include]
  --oldincludedir=DIRC header files for non-gcc [/usr/include]
  --infodir=DIR  info documentation [PREFIX/info]
  --mandir=DIR   man documentation [PREFIX/man]
--

The only options meaningful to LyX are --bindir, --datadir, --mandir, and
perhaps --libdir. Then, depending on packaging, configure does this:

case $lyx_use_packaging in
   macosx)
cat >>confdefs.h <<\_ACEOF
#define USE_MACOSX_PACKAGING 1
_ACEOF

   PACKAGE=LyX${version_suffix}
   default_prefix="/Applications/${PACKAGE}.app"
   bindir='${prefix}/Contents/MacOS'
   libdir='${prefix}/Contents/Resources'
   datadir='${prefix}/Contents/Resources'
   pkgdatadir='${datadir}'
   mandir='${datadir}/man' ;;
  windows)
cat >>confdefs.h <<\_ACEOF
#define USE_WINDOWS_PACKAGING 1
_ACEOF

   PACKAGE=LyX${version_suffix}
   default_prefix="C:/Program Files/${PACKAGE}"
   bindir='${prefix}/bin'
   libdir='${prefix}/Resources'
   datadir='${prefix}/Resources'
   pkgdatadir='${datadir}'
   mandir='${prefix}/Resources/man' ;;
posix)
cat >>confdefs.h <<\_ACEOF
#define USE_POSIX_PACKAGING 1
_ACEOF

   PACKAGE=lyx${version_suffix}
   program_suffix=$version_suffix
   pkgdatadir='${datadir}/${PACKAGE}'
   default_prefix=$ac_default_prefix ;;
*)
lyx_error_txt="$lyx_error_txt
** Unknown packaging type $lyx_use_packaging
"
lyx_error=yes ;;
esac


So, if I am not mistaken, those options are fully respected only with
posix packaging.

-- 
Enrico

Re: Compiling LyX 1.5 with scons

[Bo Peng]

 I don't think
that scons let you choose these locations independently of each other,
though. Bo?


It is not difficult at all to add these options, but will lyx know
where to find these files?

Bo

Re: Compiling LyX 1.5 with scons

[Enrico Forestieri]

On Fri, Sep 15, 2006 at 12:52:46PM -0500, Bo Peng wrote:

> > Thanks, it compiles now and run for me.
> >
> > Is there a special scons command to install lyx and create the sysdir
> > somewhere ?
> 
> What is sysdir for? I do not have this option yet. You can do
> 
> scons   DESTDIR=/path/to/dest  install
> 
> to install everything to /path/to/dest. Let me know what is under
> sysdir and under what condition they would better be placed somewhere
> else.

I think that Charles means the LyX system directory. In this case when
you compile using

scons ... prefix=/usr/local install

the sysdir will be placed in /usr/local/share/lyx, the binaries in
/usr/local/bin, and the man pages in /usr/local/man. I don't think
that scons let you choose these locations independently of each other,
though. Bo?

-- 
Enrico

Re: Compiling LyX 1.5 with scons

[Bo Peng]

Thanks, it compiles now and run for me.

Is there a special scons command to install lyx and create the sysdir
somewhere ?


What is sysdir for? I do not have this option yet. You can do

scons   DESTDIR=/path/to/dest  install

to install everything to /path/to/dest. Let me know what is under
sysdir and under what condition they would better be placed somewhere
else.

Cheers,
Bo

Re: Compiling LyX 1.5 with scons

[Charles de Miramon]

Bo Peng wrote:

>> Maybe lyx::char_type is not wchar_t because you forgot to define
>> HAVE_WCHAR_T? Or SIZEOF_WCHAR_T is not 4. Did you double check?
> 
> Well, I was bitten by the separation of config.h... HAVE_WCHAR_T is
> defined only in boost/config.h, not in other config files. A patch
> that fixes the crash will be applied soon to fix this problem.
> 
> Thanks.
> Bo

Thanks, it compiles now and run for me. 

Is there a special scons command to install lyx and create the sysdir
somewhere ?

Cheers, 
Charles
-- 
http://www.kde-france.org

Re: Compiling LyX 1.5 with scons

[Bo Peng]

Maybe lyx::char_type is not wchar_t because you forgot to define
HAVE_WCHAR_T? Or SIZEOF_WCHAR_T is not 4. Did you double check?


Well, I was bitten by the separation of config.h... HAVE_WCHAR_T is
defined only in boost/config.h, not in other config files. A patch
that fixes the crash will be applied soon to fix this problem.

Thanks.
Bo

Re: Compiling LyX 1.5 with scons

[Jean-Marc Lasgouttes]

> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Peter Kümmel wrote:
>> Indeeed, there are two definitions of floatname(...): insetwrap.C
>> and insetfloat. One should be removed.

Georg> There is some duplicate code in insetwrap and insetfloat. One
Georg> should think about subclassing or something like that, but
Georg> nevertheless the linker should not complain because both
Georg> floatname(...) are in anon namespaces.

Actually, the two insets should be merged. This would not be very
difficult, they are almost identical.

JMarc

Re: Compiling LyX 1.5 with scons

[Georg Baum]

Bo Peng wrote:

> terminate called after throwing an instance of 'std::bad_cast'
>   what():  St8bad_cast
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 182896208448 (LWP 31188)]
> 0x003c8962e21d in raise () from /lib64/tls/libc.so.6
> (gdb) bt
> #0  0x003c8962e21d in raise () from /lib64/tls/libc.so.6
> #1  0x003c8962fa1e in abort () from /lib64/tls/libc.so.6
> #2  0x003c8c5b10a8 in __gnu_cxx::__verbose_terminate_handler ()
>from /usr/lib64/libstdc++.so.6
> #3  0x003c8c5af0d6 in __cxa_call_unexpected ()
>from /usr/lib64/libstdc++.so.6
> #4  0x003c8c5af103 in std::terminate () from /usr/lib64/libstdc++.so.6
> #5  0x003c8c5af203 in __cxa_throw () from /usr/lib64/libstdc++.so.6
> #6  0x003c8c551052 in std::__throw_bad_cast ()
>from /usr/lib64/libstdc++.so.6
> #7  0x00a07abb in use_facet >
> (__loc=Variable "__loc" is not available.

Obviously gcc 3.4 has some ctype problem on x86 for wchar_t. Both gcc 3.3
and 4.1 work for me on 32bit systems.

Maybe lyx::char_type is not wchar_t because you forgot to define
HAVE_WCHAR_T? Or SIZEOF_WCHAR_T is not 4. Did you double check?

Does it work if you put the ctype code in os_win32.C from my latest stream
patch in os_unix.C?


Georg

Re: Compiling LyX 1.5 with scons

[Bo Peng]

> The scons fix is in. Lyx can start, but crashes when I open a help
> document.

Which OS? backtrace?


RHEL4, x86-64. SIZEOF_WCHAR_T is 4.

Same as entered returned
Same as entered returned
Same as entered returned
Same as entered returned
Same as entered returned
Drawing string
Drawing lyx::char_type const * s
Same as entered returned
terminate called after throwing an instance of 'std::bad_cast'
 what():  St8bad_cast

Program received signal SIGABRT, Aborted.
[Switching to Thread 182896208448 (LWP 31188)]
0x003c8962e21d in raise () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x003c8962e21d in raise () from /lib64/tls/libc.so.6
#1  0x003c8962fa1e in abort () from /lib64/tls/libc.so.6
#2  0x003c8c5b10a8 in __gnu_cxx::__verbose_terminate_handler ()
  from /usr/lib64/libstdc++.so.6
#3  0x003c8c5af0d6 in __cxa_call_unexpected ()
  from /usr/lib64/libstdc++.so.6
#4  0x003c8c5af103 in std::terminate () from /usr/lib64/libstdc++.so.6
#5  0x003c8c5af203 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6  0x003c8c551052 in std::__throw_bad_cast ()
  from /usr/lib64/libstdc++.so.6
#7  0x00a07abb in use_facet >
(__loc=Variable "__loc" is not available.
)
   at 
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/locale_facets.tcc:112
#8  0x00a06992 in boost::basic_format, std::allocator >::parse
(this=0x7fbfffdfa0,
   [EMAIL PROTECTED]) at boost/boost/format/parsing.hpp:403
#9  0x00a06286 in basic_format (this=0x7fbfffdfa0, [EMAIL PROTECTED])
   at boost/boost/format/format_implementation.hpp:64
#10 0x00a042d5 in
lyx::support::bformat, std::allocator > >
(fmt=Variable "fmt" is not available.
)
   at src/support/lstrings.C:704
#11 0x0054c9a7 in LyXFunc::dispatch (this=0xfacfb0, [EMAIL PROTECTED])
   at src/lyxfunc.C:1038
#12 0x0092a5b0 in lyx::frontend::QtView::activated
(this=Variable "this" is not available.
)
   at src/frontends/LyXView.h:91
#13 0x00942e0e in lyx::frontend::QLPopupMenu::fire (this=0xfcdd60,
   index=Variable "index" is not available.
) at src/frontends/qt3/QLPopupMenu.C:104
#14 0x00943ad4 in lyx::frontend::QLPopupMenu::qt_invoke (
   this=0xfcdd60, _id=58, _o=0x7fbfffe650)
   at /usr/lib64/qt-3.3/include/private/qucom_p.h:388
#15 0x003a7934ac58 in QObject::activate_signal ()
  from /usr/lib64/qt-3.3/lib/libqt-mt.so.3
#16 0x003a7934b25f in QObject::activate_signal ()

Re: Compiling LyX 1.5 with scons

[Georg Baum]

Bo Peng wrote:

> The scons fix is in. Lyx can start, but crashes when I open a help
> document.

Which OS? backtrace?


Georg

Re: Compiling LyX 1.5 with scons

[Georg Baum]

Peter Kümmel wrote:

> Indeeed, there are two definitions of floatname(...): insetwrap.C and
> insetfloat. One should be removed.

There is some duplicate code in insetwrap and insetfloat. One should think
about subclassing or something like that, but nevertheless the linker
should not complain because both floatname(...) are in anon namespaces.


Georg

Re: Compiling LyX 1.5 with scons

[Georg Baum]

[EMAIL PROTECTED] wrote:

> insets/.libs/libinsets.a(insetwrap.o): In function
> `__gnu_cxx::new_allocator::deallocate(CursorSlice*, un
> signed int)':
> /usr/local/src/lyx-cvs/lyx-devel/src/insets/insetwrap.C:49: multiple
> definition of `(anonymous namespace)::floatname(s
> td::basic_string, std::allocator >
> const&, BufferParams const&)'
>
insets/.libs/libinsets.a(insetfloat.o):/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetfloat.C:119:
> first defined here
> /usr/bin/ld: Warning: size of symbol `(anonymous
> namespace)::floatname(std::basic_string,
> std::allocator > const&, BufferParams const&)' changed from 2850 in
> insets/.libs/libinsets.a(insetfloat.o) to 3717 in
> insets/.libs/libinsets.a(insetwrap.o)
> collect2: ld returned 1 exit status

That problem seems to be cured by configuring with --disable-pch. Nobody
knows why it occurs for some people, while it does not for others using the
same compiler.


Georg

Re: Compiling LyX 1.5 with scons

[Bo Peng]

Missing scons support for SIZEOF_WCHAR_T. It will probably work with
autotools or if you add


The scons fix is in. Lyx can start, but crashes when I open a help document.

Bo

Re: Compiling LyX 1.5 with scons

[Peter Kümmel]

Bo Peng wrote:
> The biggest change to your patch is that I define SIZEOF_WCHAR_T
> directly, 

That's better.

-- 
Peter Kümmel

Re: Compiling LyX 1.5 with scons

[Peter Kümmel]

[EMAIL PROTECTED] wrote:
> Hello,
> 
> I have the same error executing LyX after applying Peter's patch and trying
> Georg's workaround.
> 
> Trying to go the autotools way leads to an error in the ld phase :
> 

Indeeed, there are two definitions of floatname(...): insetwrap.C and 
insetfloat.
One should be removed.


-- 
Peter Kümmel

Re: Compiling LyX 1.5 with scons

[Bo Peng]

You could drop all size-2 relevant code.
 I've added it only for completeness.



#  define SIZEOF_WCHAR_T 2


The biggest change to your patch is that I define SIZEOF_WCHAR_T
directly, without SIZE_OF_WCHAR_T_IS_2 etc since I do not see them in
the source.

Anyway, I am applying the patch.
Bo

Re: Compiling LyX 1.5 with scons

[Georg Baum]

Bo Peng wrote:

> We do not really need SIZEOF_WCHAR_T_IS_2 and 4, right?

No.

> Then, I 
> propose the following simplified version. It will be applied if there
> is no objection.

The only thing what matters is whether it sets SIZEOF_WCHAR_T correctly. If
it does, put it in.


Georg

Re: Compiling LyX 1.5 with scons

[Peter Kümmel]

Bo Peng wrote:
>> +'SIZEOF_WCHAR_T_IS_2',
>> +'SIZEOF_WCHAR_T_IS_4',
>> +#ifdef SIZEOF_WCHAR_T_IS_2
>> +#  define SIZEOF_WCHAR_T 2
>> +#else
>> +#  ifdef SIZEOF_WCHAR_T_IS_4
>> +#define SIZEOF_WCHAR_T 4
>> +#  endif
>> +#endif
> 
> We do not really need SIZEOF_WCHAR_T_IS_2 and 4, right? Then, I
> propose the following simplified version. It will be applied if there
> is no objection.

You could drop all size-2 relevant code.
 I've added it only for completeness.

-- 
Peter Kümmel

Re: Compiling LyX 1.5 with scons

[Bo Peng]

+'SIZEOF_WCHAR_T_IS_2',
+'SIZEOF_WCHAR_T_IS_4',
+#ifdef SIZEOF_WCHAR_T_IS_2
+#  define SIZEOF_WCHAR_T 2
+#else
+#  ifdef SIZEOF_WCHAR_T_IS_4
+#define SIZEOF_WCHAR_T 4
+#  endif
+#endif


We do not really need SIZEOF_WCHAR_T_IS_2 and 4, right? Then, I
propose the following simplified version. It will be applied if there
is no objection.

Index: development/scons/SConstruct
===
--- development/scons/SConstruct(revision 14996)
+++ development/scons/SConstruct(working copy)
@@ -653,6 +653,7 @@
'CheckCXXGlobalCstd' : utils.checkCXXGlobalCstd,
'CheckLC_MESSAGES' : utils.checkLC_MESSAGES,
'CheckIconvConst' : utils.checkIconvConst,
+'CheckSizeOfWChar' : utils.checkSizeOfWChar,
}
)

@@ -981,6 +982,13 @@
# check arg types of select function
(select_arg1, select_arg234, select_arg5) = conf.CheckSelectArgType()

+# check the size of wchar_t
+sizeof_wchar_t = conf.CheckSizeOfWChar()
+# something wrong
+if sizeof_wchar_t == 0:
+print 'Error: Can not determine the size of wchar_t.'
+Exit(1)
+
#
# create config.h
result = utils.createConfigFile(conf,
@@ -1148,6 +1156,8 @@
"Define to the type of arg 2, 3, 4 for `select'."),
('#define SELECT_TYPE_ARG5 %s' % select_arg5,
"Define to the type of arg 5 for `select'."),
+('#define SIZEOF_WCHAR_T %d' % sizeof_wchar_t,
+'Define to be the size of type wchar_t'),
],
config_post =
'''/
** You should not need to change anything beyond this point */
@@ -1281,7 +1291,9 @@
),
],
extra_items = [
-('#define HAVE_ICONV 1', 'Define if iconv or libiconv
is found')
+('#define HAVE_ICONV 1', 'Define if iconv or libiconv
is found'),
+('#define SIZEOF_WCHAR_T %d' % sizeof_wchar_t,
+'Define to be the size of type wchar_t'),
],
config_post = '#endif'
)
Index: development/scons/scons_utils.py
===
--- development/scons/scons_utils.py(revision 14996)
+++ development/scons/scons_utils.py(working copy)
@@ -255,6 +255,26 @@
return ret


+def checkSizeOfWChar(conf):
+''' check the size of wchar '''
+check_sizeof_wchar = '''
+int i[ ( sizeof(wchar_t)==%d ? 1 : -1 ) ];
+int main()
+{
+return 0;
+}
+'''
+conf.Message('Check the size of wchar_t... ')
+if conf.TryLink(check_sizeof_wchar % 2, '.cpp'):
+ret = 2
+elif conf.TryLink(check_sizeof_wchar % 4, '.cpp'):
+ret = 4
+else:
+ret = 0
+conf.Result(str(ret))
+return ret
+
+
def createConfigFile(conf, config_file,
config_pre = '', config_post = '',
headers = [], functions = [], types = [], l

Re: Compiling LyX 1.5 with scons

[cmiramon]

Hello,

I have the same error executing LyX after applying Peter's patch and trying
Georg's workaround.

Trying to go the autotools way leads to an error in the ld phase :

g++ -g -O -o lyx-qt4 main.o Bidi.o BufferView.o BufferView_pimpl.o Bullet.o
BranchList.o Chktex.o Color.o CutAndPaste.
o DepTable.o FloatList.o Floating.o FontIterator.o FuncStatus.o InsetList.o
LColor.o LaTeX.o LaTeXFeatures.o LyXAction
.o MenuBackend.o ParagraphParameters.o PrinterParams.o Spacing.o Thesaurus.o
ToolbarBackend.o author.o boost.o box.o b
uffer.o buffer_funcs.o bufferlist.o bufferparams.o bufferview_funcs.o
changes.o chset.o converter.o counters.o coordca
che.o cursor.o cursor_slice.o debug.o dimension.o dociterator.o encoding.o
errorlist.o exporter.o gettext.o factory.o
format.o funcrequest.o graph.o importer.o intl.o insetiterator.o kbmap.o
kbsequence.o language.o session.o lengthcommo
n.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o lyxfind.o lyxfunc.o
lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxle
x_pimpl.o lyxrc.o lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o
lyxtextclass.o lyxtextclasslist.o lyxvc.o messages.o
 metricsinfo.o mover.o output.o outputparams.o output_docbook.o
output_latex.o output_plaintext.o paragraph.o paragrap 
h_funcs.o paragraph_pimpl.o pariterator.o ispell.o SpellBase.o rowpainter.o
sgml.o tabular.o tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o
TocBackend.o toc.o trans.o trans_mgr.o undo.o vc-backend.o version.o
vspace.o  -L/usr/lib/qt4 mathed/.libs/libmathed.a insets/.libs/libinsets.a
frontends/.libs/libfrontends.a frontends/qt4/.libs/libqt4. 
a -L/home/sesse/nmu/qt4-x11-4.1.4/lib -L/usr/X11R6/lib -lQtGui -laudio -lXt 
-lpng -lQtCore -lpthread -lXi -lXrender -l 
Xrandr -lXcursor -lXinerama /usr/lib/libfreetype.so -lfontconfig -lXext -ldl
frontends/controllers/.libs/libcontrollers.a graphics/.libs/libgraphics.a
support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboost_regex.a 
../boost/li 
bs/signals/src/.libs/libboost_signals.a 
../boost/libs/filesystem/src/.libs/libboost_filesystem.a ../boost/libs/iostrea  
   
ms/src/.libs/libboost_iostreams.a /usr/lib/libAiksaurus.so -lSM -lICE -lc -lm 
-lX11 -lz

insets/.libs/libinsets.a(insetwrap.o): In function
`__gnu_cxx::new_allocator::deallocate(CursorSlice*, un 

signed int)':
/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetwrap.C:49: multiple
definition of `(anonymous namespace)::floatname(s 
td::basic_string, std::allocator >
const&, BufferParams const&)'
insets/.libs/libinsets.a(insetfloat.o):/usr/local/src/lyx-cvs/lyx-devel/src/insets/insetfloat.C:119:
first defined here
/usr/bin/ld: Warning: size of symbol `(anonymous
namespace)::floatname(std::basic_string,   
   
std::allocator > const&, BufferParams const&)' changed from 2850 in
insets/.libs/libinsets.a(insetfloat.o) to 3717 in
insets/.libs/libinsets.a(insetwrap.o)
collect2: ld returned 1 exit status

Re: Compiling LyX 1.5 with scons

[Bo Peng]

On 9/14/06, Peter Kümmel <[EMAIL PROTECTED]> wrote:

Peter Kümmel wrote:

> + conf.Message('Check if size of whar_t  is 4 ... ')
> +ret = conf.TryLink(check_whar_t_4, '.cpp')

Will this not give an error?


Peter, thanks for your patch. I will have a look and apply if it is
not yet applied.

Bo

Re: Compiling LyX 1.5 with scons

[Peter Kümmel]

Peter Kümmel wrote:

> + conf.Message('Check if size of whar_t  is 4 ... ')
> +ret = conf.TryLink(check_whar_t_4, '.cpp')

Will this not give an error?



-- 
Peter Kümmel
Index: SConstruct
===
--- SConstruct  (revision 14991)
+++ SConstruct  (working copy)
@@ -653,6 +653,8 @@
 'CheckCXXGlobalCstd' : utils.checkCXXGlobalCstd,
 'CheckLC_MESSAGES' : utils.checkLC_MESSAGES,
 'CheckIconvConst' : utils.checkIconvConst,
+'CheckWhar2' : utils.checkWhar_t_2
+'CheckWhar4' : utils.checkWhar_t_4
 }
 )
 
@@ -1077,6 +1079,14 @@
 '#define ICONV_CONST const',
 '#define ICONV_CONST',
 ),
+   (conf.CheckWhar2(),
+'SIZEOF_WCHAR_T_IS_2',
+'Define if size of whar_t is 2'
+),
+   (conf.CheckWhar4(),
+'SIZEOF_WCHAR_T_IS_4',
+'Define if size of whar_t is 4'
+),
 (conf.CheckLC_MESSAGES(),
 'HAVE_LC_MESSAGES',
 'Define if your  file defines LC_MESSAGES.'
@@ -1170,6 +1180,14 @@
 
 #include <../boost/config.h>
 
+#ifdef SIZEOF_WCHAR_T_IS_2 
+#  define SIZEOF_WCHAR_T 2 
+#else 
+#  ifdef SIZEOF_WCHAR_T_IS_4 
+#define SIZEOF_WCHAR_T 4 
+#  endif 
+#endif 
+
 #endif
 '''
 )
@@ -1270,6 +1288,14 @@
 '#define ICONV_CONST const',
 '#define ICONV_CONST',
 ),
+(conf.CheckWhar2(),
+'SIZEOF_WCHAR_T_IS_2',
+'Define if size of whar_t is 2'
+),
+(conf.CheckWhar4(),
+'SIZEOF_WCHAR_T_IS_4',
+'Define if size of whar_t is 4'
+),
 (conf.CheckType('intmax_t', includes='#include ') or 
\
 conf.CheckType('intmax_t', includes='#include '),
 'HAVE_INTMAX_T',
Index: scons_utils.py
===
--- scons_utils.py  (revision 14991)
+++ scons_utils.py  (working copy)
@@ -254,7 +254,28 @@
 conf.Result(ret)
 return ret
 
+def checkWhar_t_2(conf):
+''' check if size of whar_t is 2 '''
+check_whar_t_2 = '''
+int i[ ( sizeof(wchar_t)==2 ? 1 : -1 ) ]; 
+int main(){return 0;} 
+'''
+conf.Message('Check if size of whar_t  is 2 ... ')
+ret = conf.TryLink(check_whar_t_2, '.cpp')
+conf.Result(ret)
+return ret
 
+def checkWhar_t_4(conf):
+''' check if size of whar_t is 4 '''
+check_whar_t_4 = '''
+int i[ ( sizeof(wchar_t)==4 ? 1 : -1 ) ]; 
+int main(){return 0;} 
+'''
+conf.Message('Check if size of whar_t  is 4 ... ')
+ret = conf.TryLink(check_whar_t_4, '.cpp')
+conf.Result(ret)
+return ret
+
 def createConfigFile(conf, config_file,
 config_pre = '', config_post = '',
 headers = [], functions = [], types = [], libs = [],

Re: Compiling LyX 1.5 with scons

[Peter Kümmel]

Georg Baum wrote:
> Missing scons support for SIZEOF_WCHAR_T. 

here an untested patch which maybe needs some small fixes.

-- 
Peter Kümmel
Index: SConstruct
===
--- SConstruct  (revision 14991)
+++ SConstruct  (working copy)
@@ -653,6 +653,8 @@
 'CheckCXXGlobalCstd' : utils.checkCXXGlobalCstd,
 'CheckLC_MESSAGES' : utils.checkLC_MESSAGES,
 'CheckIconvConst' : utils.checkIconvConst,
+'CheckWhar2' : utils.checkWhar_t_2
+'CheckWhar4' : utils.checkWhar_t_4
 }
 )
 
@@ -1077,6 +1079,14 @@
 '#define ICONV_CONST const',
 '#define ICONV_CONST',
 ),
+   (conf.CheckWhar2(),
+'SIZEOF_WCHAR_T_IS_2',
+'Define if size of whar_t is 2'
+),
+   (conf.CheckWhar4(),
+'SIZEOF_WCHAR_T_IS_4',
+'Define if size of whar_t is 4'
+),
 (conf.CheckLC_MESSAGES(),
 'HAVE_LC_MESSAGES',
 'Define if your  file defines LC_MESSAGES.'
@@ -1170,6 +1180,14 @@
 
 #include <../boost/config.h>
 
+#ifdef SIZEOF_WCHAR_T_IS_2 
+#  define SIZEOF_WCHAR_T 2 
+#else 
+#  ifdef SIZEOF_WCHAR_T_IS_4 
+#define SIZEOF_WCHAR_T 4 
+#  endif 
+#endif 
+
 #endif
 '''
 )
@@ -1270,6 +1288,14 @@
 '#define ICONV_CONST const',
 '#define ICONV_CONST',
 ),
+(conf.CheckWhar2(),
+'SIZEOF_WCHAR_T_IS_2',
+'Define if size of whar_t is 2'
+),
+(conf.CheckWhar4(),
+'SIZEOF_WCHAR_T_IS_4',
+'Define if size of whar_t is 4'
+),
 (conf.CheckType('intmax_t', includes='#include ') or 
\
 conf.CheckType('intmax_t', includes='#include '),
 'HAVE_INTMAX_T',
Index: scons_utils.py
===
--- scons_utils.py  (revision 14991)
+++ scons_utils.py  (working copy)
@@ -254,7 +254,28 @@
 conf.Result(ret)
 return ret
 
+def checkWhar_t_2(conf):
+''' check if size of whar_t is 2 '''
+check_whar_t_2 = '''
+int i[ ( sizeof(wchar_t)==2 ? 1 : -1 ) ]; 
+int main(){return 0;} 
+'''
+conf.Message('Check if size of whar_t  is 2 ... ')
+ret = conf.TryLink(check_whar_t_2, '.cpp')
+conf.Result(ret)
+return ret
 
+def checkWhar_t_4(conf):
+''' check if size of whar_t is 4 '''
+check_whar_t_4 = '''
+int i[ ( sizeof(wchar_t)==4 ? 1 : -1 ) ]; 
+int main(){return 0;} 
+'''
+ conf.Message('Check if size of whar_t  is 4 ... ')
+ret = conf.TryLink(check_whar_t_4, '.cpp')
+conf.Result(ret)
+return ret
+
 def createConfigFile(conf, config_file,
 config_pre = '', config_post = '',
 headers = [], functions = [], types = [], libs = [],

Re: Compiling LyX 1.5 with scons

[Georg Baum]

[EMAIL PROTECTED] wrote:

> [EMAIL PROTECTED]:/usr/local/src/lyx-cvs/lyx-devel/development/scons/debug$
> ./lyx-qt4 Same as entered returned
> terminate called after throwing an instance of 'std::bad_cast'
>   what():  St8bad_cast
> Abandon
> 
> I'm again clueless...

Missing scons support for SIZEOF_WCHAR_T. It will probably work with
autotools or if you add

#define SIZEOF_WCHAR_T 4

to config.h as a temporary workaround.


Georg

Re: Compiling LyX 1.5 with scons

[José Matos]

On Thursday 14 September 2006 10:01, [EMAIL PROTECTED] wrote:
> I'm again clueless...

  Now you are on par with the rest of us. ;-)

  The issue is being handled by Georg, so it is a know issue.

> Cheers,
> Charles

-- 
José Abílio

Re: Compiling LyX 1.5 with scons

[cmiramon]

Hello,

I'm making progress :

- installing libqt4-debug and libqt4-dev-debug
- Running update-alternatives --config moc and update-alternatives --config
uic to point to qt4 version
- changing QTDIR to /usr/share/qt4 (don't know if its necessary)

I'm able to compile lyx-qt4

But when I execute it, it crashes with this message :


[EMAIL PROTECTED]:/usr/local/src/lyx-cvs/lyx-devel/development/scons/debug$ 
./lyx-qt4
Same as entered returned
terminate called after throwing an instance of 'std::bad_cast'
  what():  St8bad_cast
Abandon

I'm again clueless...

Cheers,
Charles

Re: Compiling LyX 1.5 with scons

[Sven Hoexter]

On Wed, Sep 13, 2006 at 07:23:55PM -0500, Bo Peng wrote:
> >I'm wondering if it does not pick the wrong moc. On Debian, moc is called
> >moc-qt4
> 
> Why is it so? Is there a moc-qt3?
Yes and a symlink "moc" managed via update-alternatives pointing to the
current Debian default.

Yes sometimes Debian is little bit different.

Cheers,
Sven
-- 
If you won't forgive me the rest of my life
Let me apologize while I'm still alive
I know it's time to face all of my past mistakes
  [Less than Jake - Rest Of My Life]

Re: Compiling LyX 1.5 with scons

[Bo Peng]

I'm wondering if it does not pick the wrong moc. On Debian, moc is called
moc-qt4


Why is it so? Is there a moc-qt3?

Bo

Re: Compiling LyX 1.5 with scons

[cmiramon]

With your patch, it compiles but stops with the qt4 frontend :
scons frontend=qt4 qt_dir=/usr/share/qt4 qt_lib_path=/usr/lib/qt4 -j3 lyx   


g++ -o
debug/common/frontends/qt4/Action.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Action.C
g++ -o
debug/common/frontends/qt4/Alert_pimpl.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Alert_pimpl.C
g++ -o
debug/common/frontends/qt4/Application.o -c -g -O -DHAVE_CONFIG_H 
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_GUI_LIB 
-Idebug/common -I/usr/local/src/lyx-cvs/lyx-devel/src 
-I/usr/local/src/lyx-cvs/lyx-devel/src -I/usr/local/src/lyx-cvs/lyx-devel/boost 
-Idebug/intl -I/usr/local/src/lyx-cvs/lyx-devel/intl -I/usr/share/qt4/include 
-Idebug/common/images -I/usr/local/src/lyx-cvs/lyx-devel/src/images 
-Idebug/common/frontends -I/usr/local/src/lyx-cvs/lyx-devel/src/frontends 
-Idebug/common/frontends/qt4 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4 
-Idebug/common/frontends/controllers 
-I/usr/local/src/lyx-cvs/lyx-devel/src/frontends/controllers -I/usr/include/qt4 
/usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Application.C
In file included
from /usr/local/src/lyx-cvs/lyx-devel/src/frontends/qt4/Action.C:13:

I'm wondering if it does not pick the wrong moc. On Debian, moc is called
moc-qt4

Cheers,
Charles

Re: Compiling LyX 1.5 with scons

[Charles de Miramon]

Bo Peng wrote:

>> I need to investigate this problem more.
> 
> Can you compile the following .c code without libiconv installed, by
> using glibc or something else?
> 
> #include 
> #include 
> int main() {
> iconv_t cd = iconv_open("","");
> iconv(cd,NULL,NULL,NULL,NULL);
> iconv_close(cd);
> }
> 
> You can modify the code, add -l to gcc... On my system, I can not
> compile it without (-liconv). I guess your system has different
> iconv.h?
> 
> Thanks.
> Bo

Here (Debian Sid), it compiles

Cheers,
Charles
-- 
http://www.kde-france.org

Re: Compiling LyX 1.5 with scons

[Bo Peng]

On 9/13/06, Bo Peng <[EMAIL PROTECTED]> wrote:

> I need to investigate this problem more.


Could you please test the attached patch? I have added a check for
iconv function, without those libs.

Index: development/scons/SConstruct
===
--- development/scons/SConstruct(revision 14988)
+++ development/scons/SConstruct(working copy)
@@ -673,12 +673,12 @@
or (use_vc and not conf.CheckLibWithHeader('zdll', 'zlib.h', 'C')):
print 'Did not find zdll.lib or zlib.h, exiting!'
Exit(1)
-has_iconv = conf.CheckLib('iconv')
-has_libiconv = conf.CheckLib('libiconv')
-if has_iconv:
-env['ICONV_LIB'] = 'iconv'
-elif has_libiconv:
-env['ICONV_LIB'] = 'libiconv'
+if conf.CheckLib('iconv'):
+env['ICONV_LIB'] = ['iconv']
+elif conf.CheckLib('libiconv'):
+env['ICONV_LIB'] = ['libiconv']
+elif conf.CheckFunc('iconv_open'):
+env['ICONV_LIB'] = []
else:
print 'Did not find iconv or libiconv, exiting!'
Exit(1)
@@ -1356,19 +1356,20 @@
frontend_libs = [x + qt_lib_suffix for x in qt_libs]


+system_libs = env['ICONV_LIB']
if platform_name in ['win32', 'cygwin']:
# the final link step needs stdc++ to succeed under mingw
# FIXME: shouldn't g++ automatically link to stdc++?
if use_vc:
-system_libs = [env['ICONV_LIB'], 'ole32', 'shlwapi',
'shell32', 'advapi32', 'zdll']
+system_libs += ['ole32', 'shlwapi', 'shell32', 'advapi32', 'zdll']
else:
-system_libs = [env['ICONV_LIB'], 'shlwapi', 'stdc++', 'z']
+system_libs += ['shlwapi', 'stdc++', 'z']
elif platform_name == 'cygwin' and env['X11']:
-system_libs = [env['ICONV_LIB'], 'GL',  'Xmu', 'Xi', 'Xrender', 'Xrandr',
+system_libs += ['GL',  'Xmu', 'Xi', 'Xrender', 'Xrandr',
'Xcursor', 'Xft', 'freetype', 'fontconfig', 'Xext', 'X11',
'SM', 'ICE',
'resolv', 'pthread', 'z']
else:
-system_libs = [env['ICONV_LIB'], 'z']
+system_libs += ['z']

libs = [
('HAVE_LIBGDI32', 'gdi32'),


Thanks.
Bo

Re: Compiling LyX 1.5 with scons

[Bo Peng]

I need to investigate this problem more.


Can you compile the following .c code without libiconv installed, by
using glibc or something else?

#include 
#include 
int main() {
   iconv_t cd = iconv_open("","");
   iconv(cd,NULL,NULL,NULL,NULL);
   iconv_close(cd);
}

You can modify the code, add -l to gcc... On my system, I can not
compile it without (-liconv). I guess your system has different
iconv.h?

Thanks.
Bo

Re: Compiling LyX 1.5 with scons

[Bo Peng]

> I have on my system /usr/local/lib/libiconv.so ...



You have downloaded and installed manually libiconv. Is it necessary ?


I am not 100% sure. If libc or someone else provides iconv() function,
then I should not have required it in scons

I need to investigate this problem more.

Bo

Re: Compiling LyX 1.5 with scons

[Bo Peng]

There is no libiconv.so

I thought iconv functionality was covered by glibc in Linux.


I have on my system /usr/local/lib/libiconv.so ...

Bo

Re: Compiling LyX 1.5 with scons

[Charles de Miramon]

Bo Peng wrote:

>> Trying scons, I'm quickly stopped :
>>
>> tombouctou:/usr/local/src/lyx-devel# scons -f
>> development/scons/SConstruct qt_lib_path=/usr/include/qt4
>> qt_dir=/usr/include/qt4 extra_lib_path=/usr/include all
>>
>> scons: Reading SConscript files ...
>> Checking for pkg-config...yes
>> Checking for main() in C library z... yes
>> Checking for main() in C library iconv... no
>> Checking for main() in C library libiconv... no
>> Did not find iconv or libiconv, exiting!
>>
>> tombouctou:/usr/local/src/lyx-devel# whereis iconv
>> iconv: /usr/bin/iconv /usr/X11R6/bin/iconv /usr/bin/X11/iconv
>> /usr/include/iconv.h /usr/share/man/man1/iconv.1.gz
> 
> Where is libiconv.so? You need to find it and use extra_lib_path. Note
> that extra_lib_path=/usr/include  should be extra_inc_path.
> 
> Bo

There is no libiconv.so 

I thought iconv functionality was covered by glibc in Linux.

Cheers,
Charles 
-- 
http://www.kde-france.org

Re: Compiling LyX 1.5 with scons

[Bo Peng]

Trying scons, I'm quickly stopped :

tombouctou:/usr/local/src/lyx-devel# scons -f development/scons/SConstruct
qt_lib_path=/usr/include/qt4 qt_dir=/usr/include/qt4
extra_lib_path=/usr/include all

scons: Reading SConscript files ...
Checking for pkg-config...yes
Checking for main() in C library z... yes
Checking for main() in C library iconv... no
Checking for main() in C library libiconv... no
Did not find iconv or libiconv, exiting!

tombouctou:/usr/local/src/lyx-devel# whereis iconv
iconv: /usr/bin/iconv /usr/X11R6/bin/iconv /usr/bin/X11/iconv 
/usr/include/iconv.h /usr/share/man/man1/iconv.1.gz


Where is libiconv.so? You need to find it and use extra_lib_path. Note
that extra_lib_path=/usr/include  should be extra_inc_path.

Bo

Re: Compiling LyX for Windows - free MSVC available

[Angus Leeming]

Enrico Forestieri <[EMAIL PROTECTED]> writes:
> If I had been able to compile a dynamic Qt with MinGW, could I have
> linked to it an MSVC compiled LyX?

No, I don't think so. The entry point to the MinGW dll is weird, apparently. The
MSVC exe won't be able to find the way in.

(Sorry if I sound a little vague ;-))

Angus

Re: Compiling LyX for Windows - free MSVC available

[Andre Poenitz]

On Mon, Feb 06, 2006 at 11:40:10AM -0500, Paul A. Rubin wrote:
> IIRC, MSVC also uses nonstandard scoping of loop indices.  Again, my 
> memory is fuzzy, but I believe that
> 
> for (int i=1; i<10; i++) ...;
> ...
> for (int i=1; i 
> should compile correctly in any standard implementation of C/C++, but I 
> think MSVC crabs that the second occurrence of 'int i' is redefining 'i'.

This has ben changed a while ago.

Andre'

Re: Compiling LyX for Windows - free MSVC available

[Enrico Forestieri]

Angus Leeming <[EMAIL PROTECTED]> writes:

> > The problem is that you cannot compile Qt with the free MSVC, so even if
> > you can build LyX, you would be stuck.
> 
> The problem you described doesn't sound like a real problem to me. You should 
> get the Q../Free developers interested. Since they put a lot of effort into 
> creating the build scripts for non-g++ builds, I'm sure they will be 
> interested in getting things to work with the free MSVC compiler.

I think you're right, but I dumped MSVC ;-)

> > I know that an MSVC program can call a C compiled MinGW DLL, but what
> > about C++?
> 
> Sorry, I don't understand.

If I had been able to compile a dynamic Qt with MinGW, could I have
linked to it an MSVC compiled LyX?

--
Enrico