> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> It is good for building a native LyX (not dependent on cygwin)
Enrico> by using cygwin tools only.
Enrico> Jean-Marc, I am not asking to add anything. I thought I was
Enrico> answering a question by Georg. I am fine with the
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> Yes, I have to specify --with-packaging=windows, otherwise I
> Enrico> would get posix. The packaging test in configure is quite
> Enrico> simple. I don't know if it ca
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> Yes, I have to specify --with-packaging=windows, otherwise I
Enrico> would get posix. The packaging test in configure is quite
Enrico> simple. I don't know if it can be changed in the following way
Enrico> (using some sort of
Georg Baum <[EMAIL PROTECTED]> writes:
>
> Am Montag, 20. März 2006 16:45 schrieb Enrico Forestieri:
> > Jean-Marc Lasgouttes ...> writes:
> >
> > > What are the preprocessor macros that say we are in cygwin -mnocygwin
> > > mode? This is what we have to test for.
> >
> > Please, find below the
Am Montag, 20. März 2006 16:45 schrieb Enrico Forestieri:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> > What are the preprocessor macros that say we are in cygwin -mnocygwin
> > mode? This is what we have to test for.
>
> Please, find below the results obtained with and without -mno-cy
Georg Baum a écrit :
Abdelrazak Younes wrote:
I didn't know I have to go inside client for it to compile, sorry.
??? I don't need to do that (otherwise I would not have noticed, I don't use
the client)
It is neither in my trunk/Makefile nor in trunk/src/Makefile. My
configure just decided
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Abdelrazak Younes wrote:
>> I didn't know I have to go inside client for it to compile, sorry.
Georg> ??? I don't need to do that (otherwise I would not have
Georg> noticed, I don't use the client)
It does not get compiled in windows
Abdelrazak Younes wrote:
> I didn't know I have to go inside client for it to compile, sorry.
??? I don't need to do that (otherwise I would not have noticed, I don't use
the client)
> Too many sorries today :-(
No problem (but I feel a bit like a watch dog lately, which I really don't
want to
Georg Baum a écrit :
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes a écrit :
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes a écrit :
Abdelrazak> Shall I commit that?
Yes, I think so.
done.
You did not compile the client, did you?
I didn't kn
Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes a écrit :
>>> "Abdelrazak" == Abdelrazak Younes
>>> <[EMAIL PROTECTED]> writes:
>>
>> Abdelrazak> Abdelrazak Younes a écrit :
>> Abdelrazak> Shall I commit that?
>>
>> Yes, I think so.
>
> done.
You did not compile the client, did you? Th
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> What are the preprocessor macros that say we are in cygwin -mnocygwin
> mode? This is what we have to test for.
Please, find below the results obtained with and without -mno-cygwin.
Essentially, I think that in the first case the WIN32 thing (in
Jean-Marc Lasgouttes a écrit :
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes a écrit :
Abdelrazak> Shall I commit that?
Yes, I think so.
done.
Abdel
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Yep I used 'c:/' like syntax. But the --with-extra-prefix never worked
> for me, with either c:/ or /c/ style. configure just stops telling that
> it cannot find 'c' directory even though it was there.
Unlike MSYS, when using Cygwin the /c thing s
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes a écrit :
Abdelrazak> Shall I commit that?
Yes, I think so.
JMarc
Abdelrazak Younes a écrit :
Georg Baum a écrit :
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes a écrit :
buf->lyxrc.C: tempdir_path = "/tmp";
It seems that this one is overwritten in LyX::init() anyway. Remove it.
Should I update my patch with this and commit it?
I think so, but you shoul
Angus Leeming <[EMAIL PROTECTED]> writes:
> I seem to remember you stating that this dynamic conversion worked for you
> using
> a Cygwin-built LyX. I was trying to find out a little bit more about your
> setup.
> Do you use the libiconv and gettext compiled by Cygwin, did you compile your
> own?
Georg Baum a écrit :
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes a écrit :
buf->lyxrc.C: tempdir_path = "/tmp";
It seems that this one is overwritten in LyX::init() anyway. Remove it.
Should I update my patch with this and commit it?
I think so, but you should leave out the changes in cr
Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes a écrit :
buf->lyxrc.C: tempdir_path = "/tmp";
>>
>> It seems that this one is overwritten in LyX::init() anyway. Remove it.
>
> Should I update my patch with this and commit it?
I think so, but you should leave out the changes in createLyXTm
Jean-Marc Lasgouttes a écrit :
"Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
bufferlist.C: s = AddName(MakeAbsPath("/tmp/"), buf->fileName());
This one is wrong (should use package().temp_dir()), but not the
problem you see.
buf->lyxrc.C: tempdir_path = "/tmp";
It seems that this on
Enrico Forestieri <[EMAIL PROTECTED]> writes:
>> Using MSYS, I have built the libiconv package suggested by Michael and then
>> gone on to build LyX using --with-included-gettext. configure finds
>> libiconv and the build proceeds happily, but I find that the resulting .exe
>> is unable to chang
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> bufferlist.C: s = AddName(MakeAbsPath("/tmp/"), buf->fileName());
This one is wrong (should use package().temp_dir()), but not the
problem you see.
>> buf->lyxrc.C: tempdir_path = "/tmp";
It seems that this one is overwritten in LyX::
Georg Baum a écrit :
Abdelrazak Younes wrote:
I have replace those 'tmp' with 'c:/temp' in the code:
[EMAIL PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src
$ grep '/tmp' *.[Ch]
bufferlist.C: s = AddName(MakeAbsPath("/tmp/"), buf->fileName());
lyxrc.C:tempdir_path = "/tmp";
[EMAIL
Abdelrazak Younes wrote:
> I have replace those 'tmp' with 'c:/temp' in the code:
>
> [EMAIL PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src
> $ grep '/tmp' *.[Ch]
> bufferlist.C: s = AddName(MakeAbsPath("/tmp/"), buf->fileName());
> lyxrc.C:tempdir_path = "/tmp";
>
> [EMAIL PROTECT
Replying again to myself...
Abdelrazak Younes a écrit :
Replying to my self, sorry.
After a "make install", when executed for its installation directory,
the /tmp problem vanished but not the '-sysdir' one:
D:\program\lyx-svn\bin>lyx-svn.exe
Unable to determine the system directory having se
Replying to my self, sorry.
After a "make install", when executed for its installation directory,
the /tmp problem vanished but not the '-sysdir' one:
D:\program\lyx-svn\bin>lyx-svn.exe
Unable to determine the system directory having searched
D:/program/lyx-svn/share/lyx-svn/
Try the '
Enrico Forestieri a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Success! I managed to compile everything (qt4) without MSYS. There two
small problem though:
1) I have to use -sysdir option because the generated executable look
for an inexistant directory:
$ ./lyx-qt4
Unable to dete
Angus Leeming <[EMAIL PROTECTED]> writes:
> Enrico,
>
> Using MSYS, I have built the libiconv package suggested by Michael and then
> gone on to build LyX using --with-included-gettext. configure finds
> libiconv and the build proceeds happily, but I find that the resulting .exe
> is unable to
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Success! I managed to compile everything (qt4) without MSYS. There two
> small problem though:
> 1) I have to use -sysdir option because the generated executable look
> for an inexistant directory:
>
> $ ./lyx-qt4
> Unable to determine the system
Enrico Forestieri wrote:
Michael Gerz <[EMAIL PROTECTED]> writes:
Enrico Forestieri wrote:
Then why not compiling libiconv with mingw, too? It is quite strightforward
to do. As regards gettext, if you configure with --with-included-gettext,
it will be compiled alongside LyX.
Then why not kee
Michael Gerz <[EMAIL PROTECTED]> writes:
>
> Enrico Forestieri wrote:
>
> >Then why not compiling libiconv with mingw, too? It is quite strightforward
> >to do. As regards gettext, if you configure with --with-included-gettext,
> >it will be compiled alongside LyX.
> >
> >
> Then why not keepin
Abdelrazak Younes a écrit :
Enrico Forestieri a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
This is interesting. I'll try to compile for a mingw target without the
-mms-bitfield switch and see what happens... I bet nothing
I have tried that in the past but did not succeed (compiling
Michael Gerz a écrit :
Georg Baum wrote:
Because of crashes. Please read the whole thread. This has been
discussed extensively.
Funny. It means that I should have experienced crashes all the time. I
wonder why I haven't... Very strange... I will look for a bullet-proof
compilation instruct
Georg Baum wrote:
Because of crashes. Please read the whole thread. This has been discussed
extensively.
Funny. It means that I should have experienced crashes all the time. I
wonder why I haven't... Very strange... I will look for a bullet-proof
compilation instruction.
Michael
Am Sonntag, 19. März 2006 10:00 schrieb Michael Gerz:
> This is not the libiconv version that Angus and I are using! Please be
> careful with what you are doing!
We are. LyX must be compiled without -mms-bitfields, since the qt4 Open
Source edition available from trolltech is compiled without i
Michael Gerz wrote:
This is not the libiconv version that Angus and I are using! Please be
careful with what you are doing!
Ok, I see that the flag has been removed already. I will check my
installation guide before I continue complaining...
Michael
Abdelrazak Younes wrote:
I forgot about that. Are we linking with libiconv or just using
iconv.exe? Same question for gettext.
https://sourceforge.net/project/shownotes.php?release_id=389183
Says that the lib is compiled with mingw so this should not be a problem.
This is not the libiconv v
Enrico Forestieri wrote:
Then why not compiling libiconv with mingw, too? It is quite strightforward
to do. As regards gettext, if you configure with --with-included-gettext,
it will be compiled alongside LyX.
Then why not keeping the option? Why all the trouble?
Michael
Am Samstag, 18. März 2006 18:13 schrieb Enrico Forestieri:
> Georg Baum <[EMAIL PROTECTED]> writes:
> I had to compile every library I needed for building LyX, and it
> turned out that I only needed Qt, aspell, and libiconv. Nothing more.
Ah, that information was missing until now.
> So, given th
Enrico Forestieri a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
This is interesting. I'll try to compile for a mingw target without the
-mms-bitfield switch and see what happens... I bet nothing
I have tried that in the past but did not succeed (compiling from cygwin
a mingw target)
Georg Baum <[EMAIL PROTECTED]> writes:
>
> Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz:
> > Abdelrazak Younes wrote:
>
> > > I was maybe not clear... Please do the change for mingw also.
>
> Oh, I thought you were using cygwin. How did you compile qt? It should
> work if you compile it
Georg Baum a écrit :
Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz:
Abdelrazak Younes wrote:
I was maybe not clear... Please do the change for mingw also.
Oh, I thought you were using cygwin. How did you compile qt? It should
work if you compile it with -mms-bitfields.
I didn't co
Am Samstag, 18. März 2006 17:34 schrieb Abdelrazak Younes:
> I really need this option to be removed for the qt4 frontend when
> compiled with mingw. The correct solution would be to remove the option
> only for the frontends/qt4 directory but I don't know if this is
> possible with m4.
This is
Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz:
> Abdelrazak Younes wrote:
> > I was maybe not clear... Please do the change for mingw also.
Oh, I thought you were using cygwin. How did you compile qt? It should
work if you compile it with -mms-bitfields.
> It is wise to remove the option
Michael Gerz a écrit :
Abdelrazak Younes wrote:
Abdel, Georg is removing the switch only for the cygwin compiler
not mingw.
But that is what Abdel wants. Or did I misunderstand anything?
I was maybe not clear... Please do the change for mingw also.
It is wise to remove the option for min
Michael Gerz <[EMAIL PROTECTED]> writes:
> It is wise to remove the option for mingw? I think we are linking
> against a gettext and libiconv version that was (most likely) built by
> MSVC or another Non-MinGW compiler.
Then why not compiling libiconv with mingw, too? It is quite strightforward
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > This is interesting. I'll try to compile for a mingw target without the
> > -mms-bitfield switch and see what happens... I bet nothing
>
> I have tried that in the past but did not succeed (compiling from cygwin
> a mingw target). The resulting
Abdelrazak Younes wrote:
Abdel, Georg is removing the switch only for the cygwin compiler
not mingw.
But that is what Abdel wants. Or did I misunderstand anything?
I was maybe not clear... Please do the change for mingw also.
It is wise to remove the option for mingw? I think we are linki
Georg Baum a écrit :
Am Samstag, 18. März 2006 16:44 schrieb Enrico Forestieri:
Abdel, Georg is removing the switch only for the cygwin compiler
not mingw.
But that is what Abdel wants. Or did I misunderstand anything?
I was maybe not clear... Please do the change for mingw also.
Abdel.
Enrico Forestieri a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Georg Baum a écrit :
Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan:
On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
Kayvan, are you listening? Why did you introduce this option also for
cygwin?
I
Am Samstag, 18. März 2006 16:44 schrieb Enrico Forestieri:
> Abdel, Georg is removing the switch only for the cygwin compiler
> not mingw.
But that is what Abdel wants. Or did I misunderstand anything?
Georg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> This is the case according to Enrico and Abdel. I am going to
Georg> commit the attached patch to trunk unless somebody objects.
If it works, commit in branch too.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> Georg Baum a écrit :
> > Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan:
> >> On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
> >>> Kayvan, are you listening? Why did you introduce this option also for
> >>> cygwin?
> >> I th
Georg Baum a écrit :
Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan:
On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
Kayvan, are you listening? Why did you introduce this option also for
cygwin?
I think this was related to trying to compile for QT/Cygwin. If we can
compil
Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan:
> On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
> > Kayvan, are you listening? Why did you introduce this option also for
> > cygwin?
>
> I think this was related to trying to compile for QT/Cygwin. If we can
> compile for QT
On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
> Am Freitag, 17. März 2006 17:31 schrieb Enrico Forestieri:
> > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> > > > Next time I will try to get rid of it and tell you. I can't right
> now,
> > > > because building from scratch tak
Am Freitag, 17. März 2006 21:03 schrieb Enrico Forestieri:
> This was with Qt/Win, I'll later test Qt/X11 but I don't think it will
> make a difference. So, at least with cygwin, I would say that
-mms-bitfield
> is not needed. Moreover, if it is a gcc issue, why should it be needed
> with mingw?
Georg Baum <[EMAIL PROTECTED]> writes:
> That means it is necessary if you want to link against libraries compiled
> by a MS compiler, and it will hurt if you link against libraries compiled
> by gcc without this switch.
> Further investigation shows that this setting was added by Kayvan on
> 2
Am Freitag, 17. März 2006 17:31 schrieb Enrico Forestieri:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > > Next time I will try to get rid of it and tell you. I can't right
now,
> > > because building from scratch takes 1.5 hours for me.
> >
> > OK, if you confirm that you don't have any
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > Next time I will try to get rid of it and tell you. I can't right now,
> > because building from scratch takes 1.5 hours for me.
>
> OK, if you confirm that you don't have any problem without the option, I
> would suggest to just eliminate it in
Enrico Forestieri a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Dear Enrico,
I have problems with the -mms-bitfields option passed to gcc for cygwin
and Mingw ports. Is it something related to structure in memory
apparently. Do you know if it is still necessary? I would like to remo
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> Dear Enrico,
>
> I have problems with the -mms-bitfields option passed to gcc for cygwin
> and Mingw ports. Is it something related to structure in memory
> apparently. Do you know if it is still necessary? I would like to remove
> that from cy
Dear Enrico,
I have problems with the -mms-bitfields option passed to gcc for cygwin
and Mingw ports. Is it something related to structure in memory
apparently. Do you know if it is still necessary? I would like to remove
that from cygwin.m4 or create a mingw.m4 but I am not really proficient
62 matches
Mail list logo
