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
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 s
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
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/D
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]: N
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
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
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
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 sourc
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 sta
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 shoul
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 reporte
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
GuiAppli
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
t: 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
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> -- Inst
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
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 q
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 replicat
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 (
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
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
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 mai
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
>
>
> 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 com
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
> 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
> 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
pe
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 -
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 I
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
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_
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__
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
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
effor
>
> 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
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
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_
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 be
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.c
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
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 stri
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
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 rel
> 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 w
> 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
> 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 fo
"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 'mak
>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
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: co
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
>
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 prepro
> So bigger compilation units are better, right? Any tricks around this?
Andre, do you have the ratio for monolithic builds?
pavel
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 #in
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 ha
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: compil
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?
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
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 shippe
> "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 m
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
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
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
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/de
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
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
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 app
> "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 subclass
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
> 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::cha
Bo Peng wrote:
> The scons fix is in. Lyx can start, but crashes when I open a help
> document.
Which OS? backtrace?
Georg
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 bec
[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:
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
Bo Peng wrote:
> The biggest change to your patch is that I define SIZEOF_WCHAR_T
> directly,
That's better.
--
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
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
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
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_WC
+'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
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 DepTa
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
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)
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,
[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 SIZE
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
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,
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 Debi
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
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
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_clo
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
=
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
> 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
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
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...y
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
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
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++
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
1 - 100 of 184 matches
Mail list logo
