Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 can be changed in the following way Enrico (using some sort of pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. It is good for building a native LyX (not dependent on cygwin) by using cygwin tools only. Jean-Marc, I am not asking to add anything. I thought I was answering a question by Georg. I am fine with the official way of building a native version of LyX. But, as I already have cygwin, I tried and succeeded in building a native LyX with cygwin tools. It can be done, but I do not endorse it because it is much more complicated. I am fine with whatever thing you will do (or not do). -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 official way Enrico of building a native version of LyX. But, as I already have Enrico cygwin, I tried and succeeded in building a native LyX with Enrico cygwin tools. It can be done, but I do not endorse it because Enrico it is much more complicated. I am fine with whatever thing you Enrico will do (or not do). Thanks for the precisions. I think we'll leave it as it it now. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "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 pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 can be changed in the following way > Enrico> (using some sort of pseudo-code): > > Well, could you tell me again what cygwin-without-cygwin is good for? > I am wary of adding fragile code for this special case. I think that > specifying packaging=windows is OK is this case. It is good for building a native LyX (not dependent on cygwin) by using cygwin tools only. Jean-Marc, I am not asking to add anything. I thought I was answering a question by Georg. I am fine with the official way of building a native version of LyX. But, as I already have cygwin, I tried and succeeded in building a native LyX with cygwin tools. It can be done, but I do not endorse it because it is much more complicated. I am fine with whatever thing you will do (or not do). -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "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 official way Enrico> of building a native version of LyX. But, as I already have Enrico> cygwin, I tried and succeeded in building a native LyX with Enrico> cygwin tools. It can be done, but I do not endorse it because Enrico> it is much more complicated. I am fine with whatever thing you Enrico> will do (or not do). Thanks for the precisions. I think we'll leave it as it it now. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 determine the system directory having searched
d:/msys/home/yns/lyx/trunk/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment variable
LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to ...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
2) I had to hack the source code in order to replace '/tmp' with
'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
Except for that I am happy to report that I cannot see any difference
with the lyx I generated within MSYS. Except that the executable is
smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() deflt != /tmp) {
filetools.C:return createTmpDir(/tmp,
lyx_tmpdir);
filetools.C:return createTmpDir(/tmp, lyx_tmpdir);
package.C: return /tmp;
package.h: * (Eg /tmp on *nix.)
path.h: * Path p(/tmp/blah);
path.h:// Path(/tmp); // wrong
path.h:// Path p(/tmp); // right
Could someone knowledgeable tell me how to fix this cleanly? The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't it?
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
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.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
Wouldn't it make sense to fix it in svn instead of doing manually the
change? I am sure they would accept your patch.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
I have heard about this one from Michael Gerz IIRC. I am using Qt4 so
oviously I don't have this problem :-)
I think that's all. The native LyX I compile using cygwin is fully
functional and until now I have seen no side effects.
IMHO cygwin is a much better environment than MSYS and we should switch
to that if we manage to fix those problems.
Thanks for the help Enrico,
Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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\binlyx-svn.exe
Unable to determine the system directory having searched
D:/program/lyx-svn/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment variable
LYX_DIR_14x to the LyX system director
y containing the file `chkconfig.ltx'.
So, while it would be nice to be able to execute from compilation
directory it is not a major issue for now.
Abdel.
Abdelrazak Younes a écrit :
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 determine the system directory having searched
d:/msys/home/yns/lyx/trunk/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment
variable LYX_DIR_14x to the LyX system directory containing the file
`chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to
...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
2) I had to hack the source code in order to replace '/tmp' with
'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
Except for that I am happy to report that I cannot see any difference
with the lyx I generated within MSYS. Except that the executable is
smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() deflt != /tmp) {
filetools.C:return createTmpDir(/tmp,
lyx_tmpdir);
filetools.C:return createTmpDir(/tmp, lyx_tmpdir);
package.C: return /tmp;
package.h: * (Eg /tmp on *nix.)
path.h: * Path p(/tmp/blah);
path.h:// Path(/tmp); // wrong
path.h:// Path p(/tmp); // right
Could someone knowledgeable tell me how to fix this cleanly? The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't it?
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
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.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
Wouldn't it make sense to fix it in svn instead of doing manually the
change? I am sure they would accept your patch.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
I have heard about this one from Michael Gerz IIRC. I am using Qt4 so
oviously I don't have this problem :-)
I think that's all. The native LyX I
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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\binlyx-svn.exe Unable to determine the system directory having searched D:/program/lyx-svn/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system director y containing the file `chkconfig.ltx'. Actually the path D:/program/lyx-svn/share/lyx-svn/ should be correct, it's just that make install failed to copy the 'lyx-svn' directory for whatever reason: $ ls d:/program/lyx-svn/share locale Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() deflt != /tmp) {
filetools.C:return createTmpDir(/tmp,
lyx_tmpdir);
filetools.C:return createTmpDir(/tmp, lyx_tmpdir);
package.C: return /tmp;
package.h: * (Eg /tmp on *nix.)
path.h: * Path p(/tmp/blah);
path.h:// Path(/tmp); // wrong
path.h:// Path p(/tmp); // right
Could someone knowledgeable tell me how to fix this cleanly?
/tmp should never be hardcoded, if a temporary directory is needed then
package().temp_dir() should be used. Can you please create a patch?
The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't
it?
No way. LyX 1.3 did that, and it can lead to overwritten files without
warning. LyX needs a temp directory for working, and if you don't have one
then something is seriously messed up.
Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() deflt != /tmp) {
filetools.C:return createTmpDir(/tmp,
lyx_tmpdir);
filetools.C:return createTmpDir(/tmp, lyx_tmpdir);
package.C: return /tmp;
package.h: * (Eg /tmp on *nix.)
path.h: * Path p(/tmp/blah);
path.h:// Path(/tmp); // wrong
path.h:// Path p(/tmp); // right
Could someone knowledgeable tell me how to fix this cleanly?
/tmp should never be hardcoded, if a temporary directory is needed then
package().temp_dir() should be used. Can you please create a patch?
Attached. It compiles and works fine for me.
The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't
it?
No way. LyX 1.3 did that, and it can lead to overwritten files without
warning. LyX needs a temp directory for working, and if you don't have one
then something is seriously messed up.
My patch fixes that anyway. I can now execute lyx from the compilation
directory with the '-sysdir' option. But adding a '-t' option for
specifying a temp directory would be great.
Abdel.
Index: D:/msys/home/yns/lyx/trunk/src/bufferlist.C
===
--- D:/msys/home/yns/lyx/trunk/src/bufferlist.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/bufferlist.C (working copy)
@@ -333,7 +333,7 @@
// 3) In /tmp directory.
// MakeAbsPath to prepend the current
// drive letter on OS/2
- s = AddName(MakeAbsPath(/tmp/), buf-fileName());
+ s = AddName(package().temp_dir(), buf-fileName());
s += .emergency;
lyxerr ' ' s endl;
if (buf-writeFile(s)) {
Index: D:/msys/home/yns/lyx/trunk/src/client/client.C
===
--- D:/msys/home/yns/lyx/trunk/src/client/client.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/client/client.C (working copy)
@@ -458,7 +458,7 @@
}
-string mainTmp(/tmp);
+string mainTmp(package().temp_dir());
int t(vectorchar * const arg)
Index: D:/msys/home/yns/lyx/trunk/src/lyxrc.C
===
--- D:/msys/home/yns/lyx/trunk/src/lyxrc.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/lyxrc.C (working copy)
@@ -39,6 +39,7 @@
#include support/lstrings.h
#include support/os.h
#include support/userinfo.h
+#include support/package.h
namespace os = lyx::support::os;
@@ -209,7 +210,7 @@
print_paper_flag = -t;
print_paper_dimension_flag = -T;
document_path.erase();
- tempdir_path = /tmp;
+ tempdir_path = lyx::support::package().temp_dir();
view_dvi_paper_option.erase();
default_papersize = PAPER_DEFAULT;
custom_export_format = ps;
Index: D:/msys/home/yns/lyx/trunk/src/support/filetools.C
===
--- D:/msys/home/yns/lyx/trunk/src/support/filetools.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/support/filetools.C (working copy)
@@ -405,7 +405,7 @@
string const createLyXTmpDir(string const deflt)
{
- if (!deflt.empty() deflt != /tmp) {
+ if (!deflt.empty() deflt != package().temp_dir()) {
if (mkdir(deflt, 0777)) {
#ifdef __EMX__
Path p(package().user_support());
@@ -417,7 +417,7 @@
return createTmpDir(deflt, lyx_tmpdir);
} else {
// some other error occured.
- return createTmpDir(/tmp, lyx_tmpdir);
+ return createTmpDir(package().temp_dir(),
lyx_tmpdir);
}
} else
return deflt;
@@ -425,7 +425,7 @@
#ifdef __EMX__
Path p(package().user_support());
#endif
- return createTmpDir(/tmp, lyx_tmpdir);
+ return createTmpDir(package().temp_dir(), lyx_tmpdir);
}
}
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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::init() anyway. Remove it. Georg /tmp should never be hardcoded, if a temporary directory is Georg needed then package().temp_dir() should be used. Can you please Georg create a patch? I think the problem is that LyX is compiled in a cygwin-that-is-not-really-cygwin mode, and it does not understand it. What are the preprocessor macros that say we are in cygwin -mnocygwin mode? This is what we have to test for. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? I suspect that this is an hardcoded path problem. The configure script sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale and then this directory is hardcoded into the executable. So, if LyX is installed in a different place than the $prefix dir, it will be unable to find the files. Noo, there's nothing *wrong* with my build per se. All .po files (actually, the compiled .po files with .gmo extension I think) are found as expected. However, the Polish .po file is encoded using the ISO-? encoding whilst Poles using Windows will be using the CP-1251 encoding or somesuch. My understanding is that we can convert dynamically between the two so long as we have a gettext-aware libiconv (and a libiconv-aware gettext). 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? Etc, etc... Regards, Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 one is overwritten in LyX::init() anyway. Remove it. Should I update my patch with this and commit it? Georg /tmp should never be hardcoded, if a temporary directory is Georg needed then package().temp_dir() should be used. Can you please Georg create a patch? I think the problem is that LyX is compiled in a cygwin-that-is-not-really-cygwin mode, and it does not understand it. What are the preprocessor macros that say we are in cygwin -mnocygwin mode? This is what we have to test for. I think there are none in current svn, 'configure' configure for cygwin when executed from there. But it would be great if the same settings as (msys+mingw) were applied (directory structure, etc). Maybe a -with-mingw option? Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 createLyXTmpDir(). (chicken and egg problem). The tests for /tmp in createLyXTmpDir() ensure that no attempt is made to create /tmp (if somebody specifies that as temporary directory). One could of course add C:\\TEMP there if that is needed, or maybe invent some more general test. What are the preprocessor macros that say we are in cygwin -mnocygwin mode? This is what we have to test for. I think there are none in current svn, 'configure' configure for cygwin when executed from there. But it would be great if the same settings as (msys+mingw) were applied (directory structure, etc). Maybe a -with-mingw option? I would prefer automatic detection. Are you sure that gcc does not have some define that is set with -mnocygwin? Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 createLyXTmpDir().
(chicken and egg problem). The tests for /tmp in createLyXTmpDir() ensure
that no attempt is made to create /tmp (if somebody specifies that as
temporary directory). One could of course add C:\\TEMP there if that is
needed, or maybe invent some more general test.
OK. New patch attached.
/tmp works in windows when called from c/c++. It just create a tmp drive
at the root of the current drive. In my case D:/tmp. So there's no
problem here.
What are the preprocessor macros that say we are in cygwin -mnocygwin
mode? This is what we have to test for.
I think there are none in current svn, 'configure' configure for cygwin
when executed from there. But it would be great if the same settings as
(msys+mingw) were applied (directory structure, etc). Maybe a
-with-mingw option?
I would prefer automatic detection. Are you sure that gcc does not have some
define that is set with -mnocygwin?
I have to confess that I am not using this option. I have just put mingw
path before cygwin path in my environment (I don't have cygwin gcc
installed). AFAIK this is exactly the same as the -mnocygwin option.
Abdel.
Index: D:/msys/home/yns/lyx/trunk/src/bufferlist.C
===
--- D:/msys/home/yns/lyx/trunk/src/bufferlist.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/bufferlist.C (working copy)
@@ -333,7 +333,7 @@
// 3) In /tmp directory.
// MakeAbsPath to prepend the current
// drive letter on OS/2
- s = AddName(MakeAbsPath(/tmp/), buf-fileName());
+ s = AddName(package().temp_dir(), buf-fileName());
s += .emergency;
lyxerr ' ' s endl;
if (buf-writeFile(s)) {
Index: D:/msys/home/yns/lyx/trunk/src/client/client.C
===
--- D:/msys/home/yns/lyx/trunk/src/client/client.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/client/client.C (working copy)
@@ -458,7 +458,7 @@
}
-string mainTmp(/tmp);
+string mainTmp(package().temp_dir());
int t(vectorchar * const arg)
Index: D:/msys/home/yns/lyx/trunk/src/lyxrc.C
===
--- D:/msys/home/yns/lyx/trunk/src/lyxrc.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/lyxrc.C (working copy)
@@ -209,7 +209,6 @@
print_paper_flag = -t;
print_paper_dimension_flag = -T;
document_path.erase();
- tempdir_path = /tmp;
view_dvi_paper_option.erase();
default_papersize = PAPER_DEFAULT;
custom_export_format = ps;
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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? Etc, etc... I think you are referring to this post: http://article.gmane.org/gmane.editors.lyx.devel/53929 There I was trying to say that I get exactly your results as shown in http://thread.gmane.org/gmane.editors.lyx.devel/53873 when I use Polish, but I am able to get cyrillic menus instead of garbage when setting a Russian locale. I obtain similar results with a cygwin LyX (using the cygwin provided libiconv) and a native LyX (using my own compiled libiconv). I think that the circular process in building libiconv/gettext has an impact only on their own localization. Indeed, I solved the thing simply compiling with --disable-nls and thus always using english messages. So, the results I obtain with Polish are essentially as correct (wrong?) as yours, but I seem to obtain correct results with Russian. I am sorry I can't be of much help here... -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 should leave out the changes in createLyXTmpDir(). (chicken and egg problem). The tests for /tmp in createLyXTmpDir() ensure that no attempt is made to create /tmp (if somebody specifies that as temporary directory). One could of course add C:\\TEMP there if that is needed, or maybe invent some more general test. OK. New patch attached. Shall I commit that? Sorry if I asked two times but I am careful here as I don't want Lars to beat me ;-) Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Abdelrazak Younes a écrit : Abdelrazak Shall I commit that? Yes, I think so. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 should be activated by $ mount -f C: /c otherwise you have to use the /cygdrive/c style syntax. You have to issue the mount command only once as it will be stored in a mount table and used again next time. Another problem can arise when a path is autogenerated by configure. There is some code in the configure script that turns 'C:/Programs/LyX' into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your settings), so I had to add the following to the sed command I use for modifying configure: # Set locale and data dir in mixed rather than posix format /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/ otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the executable instead of 'C:/Programs/LyX/Resources/locale', and the net effect would be that setting LANG to some locale doesn't work. Thinking about it, perhaps this is the reason (hardcoded path) why Angus reports that setting LANG seems not working in mingw builds. Wouldn't it make sense to fix it in svn instead of doing manually the change? I am sure they would accept your patch. No, this is only needed when you want to build a native LyX but using the cygwin compiler. This is not supported and I don't ask that it is as I agree that it would make things more complicated than they are now. Anyway, I have my lyxconfig script that appropriately hacks 'configure' as needed, so this is not a problem for me. However, this is the only problem that I spotted. To be honest there was another one, but it was about the recognition of a multi-threaded Qt. For some reason the default test program used in configure: I have heard about this one from Michael Gerz IIRC. I am using Qt4 so oviously I don't have this problem Likely, as when using -mno-cygwin the cygwin compiler really turns into the mingw one. I think that's all. The native LyX I compile using cygwin is fully functional and until now I have seen no side effects. IMHO cygwin is a much better environment than MSYS and we should switch to that if we manage to fix those problems. I disagree, even if I do that ;-) You should have a good knowledge of the way cygwin works and be prepared to surprises. However, I may be wrong on this one. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 all its variants _WIN32, __WIN32, ...) gets defined, whereas in the second case unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). -- Enrico $ touch nonexistent.C $ g++ -dM -E -mno-cygwin nonexistent.C #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 65535U #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 2 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 4 #define _stdcall __attribute__((__stdcall__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MAX_EXP__ 16384 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ _ #define __STDC_HOSTED__ 1 #define __WIN32 1 #define __LDBL_HAS_INFINITY__ 1 #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __GXX_WEAK__ 1 #define __tune_i686__ 1 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 3 #define _cdecl __attribute__((__cdecl__)) #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define _fastcall __attribute__((__fastcall__)) #define __cplusplus 1 #define __USING_SJLJ_EXCEPTIONS__ 1 #define __DEPRECATED 1 #define __DBL_MAX_EXP__ 1024 #define __WIN32__ 1 #define __GNUG__ 3 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __DBL_MIN__ 2.2250738585072014e-308 #define __FLT_MIN_10_EXP__ (-37) #define __DBL_HAS_QUIET_NAN__ 1 #define __REGISTER_PREFIX__ #define __cdecl __attribute__((__cdecl__)) #define __NO_INLINE__ 1 #define __i386 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) #define _WIN32 1 #define _X86_ 1 #define i386 1 #define __i386__ 1 #define __SIZE_TYPE__ unsigned int #define __FLT_RADIX__ 2 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L #define __MSVCRT__ 1 #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MAX_10_EXP__ 38 #define __LONG_MAX__ 2147483647L #define __FLT_HAS_INFINITY__ 1 #define __stdcall __attribute__((__stdcall__)) #define __EXCEPTIONS 1 #define __LDBL_MANT_DIG__ 64 #define __WCHAR_TYPE__ short unsigned int #define __FLT_DIG__ 6 #define __INT_MAX__ 2147483647 #define WIN32 1 #define __MINGW32__ 1 #define __FLT_MAX_EXP__ 128 #define __DBL_MANT_DIG__ 53 #define __WINT_TYPE__ unsigned int #define __LDBL_MIN_EXP__ (-16381) #define __WCHAR_UNSIGNED__ 1 #define __LDBL_MAX_10_EXP__ 4932 #define __DBL_EPSILON__ 2.2204460492503131e-16 #define __tune_pentiumpro__ 1 #define __fastcall __attribute__((__fastcall__)) #define WINNT 1 #define __FLT_DENORM_MIN__ 1.40129846e-45F #define __FLT_MAX__ 3.40282347e+38F #define __GNUC_MINOR__ 4 #define __DBL_MAX_10_EXP__ 308 #define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L #define __PTRDIFF_TYPE__ int #define __LDBL_MIN_10_EXP__ (-4931) #define __LDBL_DIG__ 18 #define __declspec(x) __attribute__((x)) -- $ g++ -dM -E nonexistent.C #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 65535U #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 2 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 4 #define _stdcall __attribute__((__stdcall__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __unix 1 #define __LDBL_MAX_EXP__ 16384 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ _ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __GXX_WEAK__ 1 #define __tune_i686__ 1 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __unix__ 1 #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 3 #define _cdecl __attribute__((__cdecl__)) #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define _fastcall __attribute__((__fastcall__)) #define __cplusplus 1 #define __USING_SJLJ_EXCEPTIONS__ 1 #define __DEPRECATED 1 #define __DBL_MAX_EXP__ 1024 #define __GNUG__ 3 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __DBL_MIN__ 2.2250738585072014e-308 #define __FLT_MIN_10_EXP__ (-37) #define __DBL_HAS_QUIET_NAN__ 1 #define __REGISTER_PREFIX__ #define __cdecl __attribute__((__cdecl__)) #define __NO_INLINE__ 1 #define __i386 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) #define _X86_ 1
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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? The attached patch goes in now. GeorgIndex: src/client/client.C === --- src/client/client.C (Revision 13437) +++ src/client/client.C (Arbeitskopie) @@ -14,6 +14,7 @@ #include debug.h #include support/lstrings.h +#include support/package.h #include boost/filesystem/operations.hpp #include boost/lexical_cast.hpp @@ -458,7 +459,7 @@ int a(vectorchar * const arg) } -string mainTmp(package().temp_dir()); +string mainTmp(lyx::support::package().temp_dir()); int t(vectorchar * const arg)
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 know I have to go inside client for it to compile, sorry. Too many sorries today :-( Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 be ;-) Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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. No socket support. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 to not have it apparently. Too many sorries today :-( No problem (but I feel a bit like a watch dog lately, which I really don't want to be ;-) Quite understandable. Thanks, Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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-cygwin. Essentially, I think that in the first case the WIN32 thing (in all its variants _WIN32, __WIN32, ...) gets defined, whereas in the second case unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). The problem is that we would need to set the USE_WINDOWS_PACKAGING macro in configure. I believe that for now you ned to do that manually with the --with-packaging=windows switch if you use -mnocygwin. Enrico, does that work? If yes, it should probably be documented. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum [EMAIL PROTECTED] writes: Am Montag, 20. März 2006 16:45 schrieb Enrico Forestieri: Jean-Marc Lasgouttes Jean-Marc.Lasgouttes at ... 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 all its variants _WIN32, __WIN32, ...) gets defined, whereas in the second case unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). The problem is that we would need to set the USE_WINDOWS_PACKAGING macro in configure. I believe that for now you ned to do that manually with the --with-packaging=windows switch if you use -mnocygwin. Enrico, does that work? If yes, it should probably be documented. Yes, I have to specify --with-packaging=windows, otherwise I would get posix. The packaging test in configure is quite simple. I don't know if it can be changed in the following way (using some sort of pseudo-code): ... case $host in *-apple-darwin*) lyx_use_packaging=macosx ;; *-pc-mingw32*) lyx_use_packaging=windows;; *-pc-cygwin*) lyx_use_packaging=cygwin;; *) lyx_use_packaging=posix;; esac if [ $lyx_use_packaging = cygwin ]; then IF compiler defines WIN32 THEN lyx_use_packaging=windows ELSE lyx_use_packaging=posix ENDIF fi ... -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 determine the system directory having searched
d:/msys/home/yns/lyx/trunk/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment variable
LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to ...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
2) I had to hack the source code in order to replace '/tmp' with
'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
Except for that I am happy to report that I cannot see any difference
with the lyx I generated within MSYS. Except that the executable is
smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() && deflt != "/tmp") {
filetools.C:return createTmpDir("/tmp",
"lyx_tmpdir");
filetools.C:return createTmpDir("/tmp", "lyx_tmpdir");
package.C: return "/tmp";
package.h: * (Eg /tmp on *nix.)
path.h: * Path p("/tmp/blah");
path.h:// Path("/tmp"); // wrong
path.h:// Path p("/tmp"); // right
Could someone knowledgeable tell me how to fix this cleanly? The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't it?
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
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.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
Wouldn't it make sense to fix it in svn instead of doing manually the
change? I am sure they would accept your patch.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
I have heard about this one from Michael Gerz IIRC. I am using Qt4 so
oviously I don't have this problem :-)
I think that's all. The native LyX I compile using cygwin is fully
functional and until now I have seen no side effects.
IMHO cygwin is a much better environment than MSYS and we should switch
to that if we manage to fix those problems.
Thanks for the help Enrico,
Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 '-sysdir' command line parameter or set the environment variable
LYX_DIR_14x to the LyX system director
y containing the file `chkconfig.ltx'.
So, while it would be nice to be able to execute from compilation
directory it is not a major issue for now.
Abdel.
Abdelrazak Younes a écrit :
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 determine the system directory having searched
d:/msys/home/yns/lyx/trunk/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment
variable LYX_DIR_14x to the LyX system directory containing the file
`chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to
...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
2) I had to hack the source code in order to replace '/tmp' with
'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
Except for that I am happy to report that I cannot see any difference
with the lyx I generated within MSYS. Except that the executable is
smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() && deflt != "/tmp") {
filetools.C:return createTmpDir("/tmp",
"lyx_tmpdir");
filetools.C:return createTmpDir("/tmp", "lyx_tmpdir");
package.C: return "/tmp";
package.h: * (Eg /tmp on *nix.)
path.h: * Path p("/tmp/blah");
path.h:// Path("/tmp"); // wrong
path.h:// Path p("/tmp"); // right
Could someone knowledgeable tell me how to fix this cleanly? The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't it?
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
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.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
Wouldn't it make sense to fix it in svn instead of doing manually the
change? I am sure they would accept your patch.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
I have heard about this one from Michael Gerz IIRC. I am using Qt4 so
oviously I don't have this problem :-)
I think
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 searched D:/program/lyx-svn/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system director y containing the file `chkconfig.ltx'. Actually the path D:/program/lyx-svn/share/lyx-svn/ should be correct, it's just that make install failed to copy the 'lyx-svn' directory for whatever reason: $ ls d:/program/lyx-svn/share locale Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
> $ grep -r '/tmp' *.[Ch]
> filetools.C:if (!deflt.empty() && deflt != "/tmp") {
> filetools.C:return createTmpDir("/tmp",
> "lyx_tmpdir");
> filetools.C:return createTmpDir("/tmp", "lyx_tmpdir");
> package.C: return "/tmp";
> package.h: * (Eg /tmp on *nix.)
> path.h: * Path p("/tmp/blah");
> path.h:// Path("/tmp"); // wrong
> path.h:// Path p("/tmp"); // right
>
> Could someone knowledgeable tell me how to fix this cleanly?
/tmp should never be hardcoded, if a temporary directory is needed then
package().temp_dir() should be used. Can you please create a patch?
> The temp
> directory is accessible via the user settings. Why does lyx exits if it
> doesn't find it? It could instead switch to no-temp directory, couldn't
> it?
No way. LyX 1.3 did that, and it can lead to overwritten files without
warning. LyX needs a temp directory for working, and if you don't have one
then something is seriously messed up.
Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 PROTECTED] /cygdrive/d/msys/home/yns/lyx/trunk/src/support
$ grep -r '/tmp' *.[Ch]
filetools.C:if (!deflt.empty() && deflt != "/tmp") {
filetools.C:return createTmpDir("/tmp",
"lyx_tmpdir");
filetools.C:return createTmpDir("/tmp", "lyx_tmpdir");
package.C: return "/tmp";
package.h: * (Eg /tmp on *nix.)
path.h: * Path p("/tmp/blah");
path.h:// Path("/tmp"); // wrong
path.h:// Path p("/tmp"); // right
Could someone knowledgeable tell me how to fix this cleanly?
/tmp should never be hardcoded, if a temporary directory is needed then
package().temp_dir() should be used. Can you please create a patch?
Attached. It compiles and works fine for me.
The temp
directory is accessible via the user settings. Why does lyx exits if it
doesn't find it? It could instead switch to no-temp directory, couldn't
it?
No way. LyX 1.3 did that, and it can lead to overwritten files without
warning. LyX needs a temp directory for working, and if you don't have one
then something is seriously messed up.
My patch fixes that anyway. I can now execute lyx from the compilation
directory with the '-sysdir' option. But adding a '-t' option for
specifying a temp directory would be great.
Abdel.
Index: D:/msys/home/yns/lyx/trunk/src/bufferlist.C
===
--- D:/msys/home/yns/lyx/trunk/src/bufferlist.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/bufferlist.C (working copy)
@@ -333,7 +333,7 @@
// 3) In "/tmp" directory.
// MakeAbsPath to prepend the current
// drive letter on OS/2
- s = AddName(MakeAbsPath("/tmp/"), buf->fileName());
+ s = AddName(package().temp_dir(), buf->fileName());
s += ".emergency";
lyxerr << ' ' << s << endl;
if (buf->writeFile(s)) {
Index: D:/msys/home/yns/lyx/trunk/src/client/client.C
===
--- D:/msys/home/yns/lyx/trunk/src/client/client.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/client/client.C (working copy)
@@ -458,7 +458,7 @@
}
-string mainTmp("/tmp");
+string mainTmp(package().temp_dir());
int t(vector const & arg)
Index: D:/msys/home/yns/lyx/trunk/src/lyxrc.C
===
--- D:/msys/home/yns/lyx/trunk/src/lyxrc.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/lyxrc.C (working copy)
@@ -39,6 +39,7 @@
#include "support/lstrings.h"
#include "support/os.h"
#include "support/userinfo.h"
+#include "support/package.h"
namespace os = lyx::support::os;
@@ -209,7 +210,7 @@
print_paper_flag = "-t";
print_paper_dimension_flag = "-T";
document_path.erase();
- tempdir_path = "/tmp";
+ tempdir_path = lyx::support::package().temp_dir();
view_dvi_paper_option.erase();
default_papersize = PAPER_DEFAULT;
custom_export_format = "ps";
Index: D:/msys/home/yns/lyx/trunk/src/support/filetools.C
===
--- D:/msys/home/yns/lyx/trunk/src/support/filetools.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/support/filetools.C (working copy)
@@ -405,7 +405,7 @@
string const createLyXTmpDir(string const & deflt)
{
- if (!deflt.empty() && deflt != "/tmp") {
+ if (!deflt.empty() && deflt != package().temp_dir()) {
if (mkdir(deflt, 0777)) {
#ifdef __EMX__
Path p(package().user_support());
@@ -417,7 +417,7 @@
return createTmpDir(deflt, "lyx_tmpdir");
} else {
// some other error occured.
- return createTmpDir("/tmp", "lyx_tmpdir");
+ return createTmpDir(package().temp_dir(),
"lyx_tmpdir");
}
} else
return deflt;
@@ -425,7 +425,7 @@
#ifdef __EMX__
Path p(package().user_support());
#endif
- return createTmpDir("/tmp", "lyx_tmpdir");
+ return createTmpDir(package().temp_dir(), "lyx_tmpdir");
}
}
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "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::init() anyway. Remove it.
Georg> /tmp should never be hardcoded, if a temporary directory is
Georg> needed then package().temp_dir() should be used. Can you please
Georg> create a patch?
I think the problem is that LyX is compiled in a
cygwin-that-is-not-really-cygwin mode, and it does not understand it.
What are the preprocessor macros that say we are in cygwin -mnocygwin
mode? This is what we have to test for.
JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 change the installed .po (.gmo) dynamically to the local >> locale. If I understood your message of some time ago correctly, you >> reported that your essentially-identical cygwin build was able to display a >> Polish LyX with native Windows LANG. >> When I read the libiconv/gettext build docs, it seems that the build >> process is essentially circular. First build gettext, then libiconv, then >> gettext again. (Or start with libiconv, then gettext, then libiconv again.) >> So, I suspect that my build doesn't work as advertised because my build is >> incomplete. >> Before I invest time and effort into trying out my theory, can you explain >> in more detail just what you did to get this stuff working? > I suspect that this is an hardcoded path problem. The configure script > sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale > and then this directory is hardcoded into the executable. > So, if LyX is installed in a different place than the $prefix dir, it will > be unable to find the files. Noo, there's nothing *wrong* with my build per se. All .po files (actually, the compiled .po files with .gmo extension I think) are found as expected. However, the Polish .po file is encoded using the ISO-? encoding whilst Poles using Windows will be using the CP-1251 encoding or somesuch. My understanding is that we can convert dynamically between the two so long as we have a gettext-aware libiconv (and a libiconv-aware gettext). 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? Etc, etc... Regards, Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 one is overwritten in LyX::init() anyway. Remove it.
Should I update my patch with this and commit it?
Georg> /tmp should never be hardcoded, if a temporary directory is
Georg> needed then package().temp_dir() should be used. Can you please
Georg> create a patch?
I think the problem is that LyX is compiled in a
cygwin-that-is-not-really-cygwin mode, and it does not understand it.
What are the preprocessor macros that say we are in cygwin -mnocygwin
mode? This is what we have to test for.
I think there are none in current svn, 'configure' configure for cygwin
when executed from there. But it would be great if the same settings as
(msys+mingw) were applied (directory structure, etc). Maybe a
-with-mingw option?
Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 createLyXTmpDir(). (chicken and egg problem). The tests for /tmp in createLyXTmpDir() ensure that no attempt is made to create /tmp (if somebody specifies that as temporary directory). One could of course add C:\\TEMP there if that is needed, or maybe invent some more general test. >> What are the preprocessor macros that say we are in cygwin -mnocygwin >> mode? This is what we have to test for. > > I think there are none in current svn, 'configure' configure for cygwin > when executed from there. But it would be great if the same settings as > (msys+mingw) were applied (directory structure, etc). Maybe a > -with-mingw option? I would prefer automatic detection. Are you sure that gcc does not have some define that is set with -mnocygwin? Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 createLyXTmpDir().
(chicken and egg problem). The tests for /tmp in createLyXTmpDir() ensure
that no attempt is made to create /tmp (if somebody specifies that as
temporary directory). One could of course add C:\\TEMP there if that is
needed, or maybe invent some more general test.
OK. New patch attached.
/tmp works in windows when called from c/c++. It just create a tmp drive
at the root of the current drive. In my case D:/tmp. So there's no
problem here.
What are the preprocessor macros that say we are in cygwin -mnocygwin
mode? This is what we have to test for.
I think there are none in current svn, 'configure' configure for cygwin
when executed from there. But it would be great if the same settings as
(msys+mingw) were applied (directory structure, etc). Maybe a
-with-mingw option?
I would prefer automatic detection. Are you sure that gcc does not have some
define that is set with -mnocygwin?
I have to confess that I am not using this option. I have just put mingw
path before cygwin path in my environment (I don't have cygwin gcc
installed). AFAIK this is exactly the same as the -mnocygwin option.
Abdel.
Index: D:/msys/home/yns/lyx/trunk/src/bufferlist.C
===
--- D:/msys/home/yns/lyx/trunk/src/bufferlist.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/bufferlist.C (working copy)
@@ -333,7 +333,7 @@
// 3) In "/tmp" directory.
// MakeAbsPath to prepend the current
// drive letter on OS/2
- s = AddName(MakeAbsPath("/tmp/"), buf->fileName());
+ s = AddName(package().temp_dir(), buf->fileName());
s += ".emergency";
lyxerr << ' ' << s << endl;
if (buf->writeFile(s)) {
Index: D:/msys/home/yns/lyx/trunk/src/client/client.C
===
--- D:/msys/home/yns/lyx/trunk/src/client/client.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/client/client.C (working copy)
@@ -458,7 +458,7 @@
}
-string mainTmp("/tmp");
+string mainTmp(package().temp_dir());
int t(vector const & arg)
Index: D:/msys/home/yns/lyx/trunk/src/lyxrc.C
===
--- D:/msys/home/yns/lyx/trunk/src/lyxrc.C (revision 13409)
+++ D:/msys/home/yns/lyx/trunk/src/lyxrc.C (working copy)
@@ -209,7 +209,6 @@
print_paper_flag = "-t";
print_paper_dimension_flag = "-T";
document_path.erase();
- tempdir_path = "/tmp";
view_dvi_paper_option.erase();
default_papersize = PAPER_DEFAULT;
custom_export_format = "ps";
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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? Etc, etc... I think you are referring to this post: http://article.gmane.org/gmane.editors.lyx.devel/53929 There I was trying to say that I get exactly your results as shown in http://thread.gmane.org/gmane.editors.lyx.devel/53873 when I use Polish, but I am able to get cyrillic menus instead of garbage when setting a Russian locale. I obtain similar results with a cygwin LyX (using the cygwin provided libiconv) and a native LyX (using my own compiled libiconv). I think that the circular process in building libiconv/gettext has an impact only on their own localization. Indeed, I solved the thing simply compiling with --disable-nls and thus always using english messages. So, the results I obtain with Polish are essentially as correct (wrong?) as yours, but I seem to obtain correct results with Russian. I am sorry I can't be of much help here... -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 should leave out the changes in createLyXTmpDir(). (chicken and egg problem). The tests for /tmp in createLyXTmpDir() ensure that no attempt is made to create /tmp (if somebody specifies that as temporary directory). One could of course add C:\\TEMP there if that is needed, or maybe invent some more general test. OK. New patch attached. Shall I commit that? Sorry if I asked two times but I am careful here as I don't want Lars to beat me ;-) Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Abdelrazak Younes a écrit : Abdelrazak> Shall I commit that? Yes, I think so. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 should be activated by $ mount -f C: /c otherwise you have to use the /cygdrive/c style syntax. You have to issue the mount command only once as it will be stored in a mount table and used again next time. > > Another problem can arise when a path is autogenerated by configure. > > There is some code in the configure script that turns 'C:/Programs/LyX' > > into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your > > settings), so I had to add the following to the sed command I use for > > modifying configure: > > > > # Set locale and data dir in mixed rather than posix format > > /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/ > > > > otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the > > executable instead of 'C:/Programs/LyX/Resources/locale', and the net > > effect would be that setting LANG to some locale doesn't work. > > > > Thinking about it, perhaps this is the reason (hardcoded path) why > > Angus reports that setting LANG seems not working in mingw builds. > > Wouldn't it make sense to fix it in svn instead of doing manually the > change? I am sure they would accept your patch. No, this is only needed when you want to build a native LyX but using the cygwin compiler. This is not supported and I don't ask that it is as I agree that it would make things more complicated than they are now. Anyway, I have my lyxconfig script that appropriately hacks 'configure' as needed, so this is not a problem for me. > > However, this is the only problem that I spotted. To be honest there > > was another one, but it was about the recognition of a multi-threaded > > Qt. For some reason the default test program used in configure: > > I have heard about this one from Michael Gerz IIRC. I am using Qt4 so > oviously I don't have this problem Likely, as when using -mno-cygwin the cygwin compiler really turns into the mingw one. > > I think that's all. The native LyX I compile using cygwin is fully > > functional and until now I have seen no side effects. > > IMHO cygwin is a much better environment than MSYS and we should switch > to that if we manage to fix those problems. I disagree, even if I do that ;-) You should have a good knowledge of the way cygwin works and be prepared to surprises. However, I may be wrong on this one. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 all its variants _WIN32, __WIN32, ...) gets defined, whereas in the second case unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). -- Enrico $ touch nonexistent.C $ g++ -dM -E -mno-cygwin nonexistent.C #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 65535U #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 2 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 4 #define _stdcall __attribute__((__stdcall__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MAX_EXP__ 16384 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ _ #define __STDC_HOSTED__ 1 #define __WIN32 1 #define __LDBL_HAS_INFINITY__ 1 #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __GXX_WEAK__ 1 #define __tune_i686__ 1 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 3 #define _cdecl __attribute__((__cdecl__)) #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define _fastcall __attribute__((__fastcall__)) #define __cplusplus 1 #define __USING_SJLJ_EXCEPTIONS__ 1 #define __DEPRECATED 1 #define __DBL_MAX_EXP__ 1024 #define __WIN32__ 1 #define __GNUG__ 3 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __DBL_MIN__ 2.2250738585072014e-308 #define __FLT_MIN_10_EXP__ (-37) #define __DBL_HAS_QUIET_NAN__ 1 #define __REGISTER_PREFIX__ #define __cdecl __attribute__((__cdecl__)) #define __NO_INLINE__ 1 #define __i386 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ "3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)" #define _WIN32 1 #define _X86_ 1 #define i386 1 #define __i386__ 1 #define __SIZE_TYPE__ unsigned int #define __FLT_RADIX__ 2 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L #define __MSVCRT__ 1 #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MAX_10_EXP__ 38 #define __LONG_MAX__ 2147483647L #define __FLT_HAS_INFINITY__ 1 #define __stdcall __attribute__((__stdcall__)) #define __EXCEPTIONS 1 #define __LDBL_MANT_DIG__ 64 #define __WCHAR_TYPE__ short unsigned int #define __FLT_DIG__ 6 #define __INT_MAX__ 2147483647 #define WIN32 1 #define __MINGW32__ 1 #define __FLT_MAX_EXP__ 128 #define __DBL_MANT_DIG__ 53 #define __WINT_TYPE__ unsigned int #define __LDBL_MIN_EXP__ (-16381) #define __WCHAR_UNSIGNED__ 1 #define __LDBL_MAX_10_EXP__ 4932 #define __DBL_EPSILON__ 2.2204460492503131e-16 #define __tune_pentiumpro__ 1 #define __fastcall __attribute__((__fastcall__)) #define WINNT 1 #define __FLT_DENORM_MIN__ 1.40129846e-45F #define __FLT_MAX__ 3.40282347e+38F #define __GNUC_MINOR__ 4 #define __DBL_MAX_10_EXP__ 308 #define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L #define __PTRDIFF_TYPE__ int #define __LDBL_MIN_10_EXP__ (-4931) #define __LDBL_DIG__ 18 #define __declspec(x) __attribute__((x)) -- $ g++ -dM -E nonexistent.C #define __DBL_MIN_EXP__ (-1021) #define __FLT_MIN__ 1.17549435e-38F #define __CHAR_BIT__ 8 #define __WCHAR_MAX__ 65535U #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __FLT_EVAL_METHOD__ 2 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 4 #define _stdcall __attribute__((__stdcall__)) #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __unix 1 #define __LDBL_MAX_EXP__ 16384 #define __SCHAR_MAX__ 127 #define __USER_LABEL_PREFIX__ _ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __DBL_DIG__ 15 #define __FLT_EPSILON__ 1.19209290e-7F #define __GXX_WEAK__ 1 #define __tune_i686__ 1 #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __unix__ 1 #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 3 #define _cdecl __attribute__((__cdecl__)) #define __DBL_MAX__ 1.7976931348623157e+308 #define __DBL_HAS_INFINITY__ 1 #define _fastcall __attribute__((__fastcall__)) #define __cplusplus 1 #define __USING_SJLJ_EXCEPTIONS__ 1 #define __DEPRECATED 1 #define __DBL_MAX_EXP__ 1024 #define __GNUG__ 3 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __DBL_MIN__ 2.2250738585072014e-308 #define __FLT_MIN_10_EXP__ (-37) #define __DBL_HAS_QUIET_NAN__ 1 #define __REGISTER_PREFIX__ #define __cdecl __attribute__((__cdecl__)) #define __NO_INLINE__ 1 #define __i386 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ "3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)" #define
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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? The attached patch goes in now. GeorgIndex: src/client/client.C === --- src/client/client.C (Revision 13437) +++ src/client/client.C (Arbeitskopie) @@ -14,6 +14,7 @@ #include "debug.h" #include "support/lstrings.h" +#include "support/package.h" #include #include @@ -458,7 +459,7 @@ int a(vector const & arg) } -string mainTmp(package().temp_dir()); +string mainTmp(lyx::support::package().temp_dir()); int t(vector const & arg)
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 know I have to go inside client for it to compile, sorry. Too many sorries today :-( Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 be ;-) Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "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. No socket support. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 to not have it apparently. Too many sorries today :-( No problem (but I feel a bit like a watch dog lately, which I really don't want to be ;-) Quite understandable. Thanks, Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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-cygwin. > Essentially, I think that in the first case the WIN32 thing (in all its > variants _WIN32, __WIN32, ...) gets defined, whereas in the second case > unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). The problem is that we would need to set the USE_WINDOWS_PACKAGING macro in configure. I believe that for now you ned to do that manually with the --with-packaging=windows switch if you use -mnocygwin. Enrico, does that work? If yes, it should probably be documented. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 results obtained with and without -mno-cygwin. > > Essentially, I think that in the first case the WIN32 thing (in all its > > variants _WIN32, __WIN32, ...) gets defined, whereas in the second case > > unix and variants gets defined (other than __CYGWIN__ and __CYGWIN32__). > > The problem is that we would need to set the USE_WINDOWS_PACKAGING macro > in configure. I believe that for now you ned to do that manually with the > --with-packaging=windows switch if you use -mnocygwin. Enrico, does that > work? If yes, it should probably be documented. Yes, I have to specify --with-packaging=windows, otherwise I would get posix. The packaging test in configure is quite simple. I don't know if it can be changed in the following way (using some sort of pseudo-code): ... case $host in *-apple-darwin*) lyx_use_packaging=macosx ;; *-pc-mingw32*) lyx_use_packaging=windows;; *-pc-cygwin*) lyx_use_packaging=cygwin;; *) lyx_use_packaging=posix;; esac if [ $lyx_use_packaging = cygwin ]; then IF compiler defines WIN32 THEN lyx_use_packaging=windows ELSE lyx_use_packaging=posix ENDIF fi ... -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 that those libraries don't use -mms-bitfields, I think it is
safe avoiding it. Moreover, if those libraries don't use -mms-bitfields
and you enforce it, problems arise (see Abdel case).
I agree. If these libraries don't use -mms-bitfield then LyX must not use
it either. I had a look at the qt3 port for windows, and it does not use
it either in the default configuration for mingw and cygwin. So even if
we wanted to use other libraries that would require the switch we cannot
do so because qt3 does not use it.
Those who compile qt3 with nonstandard settings know what they are doing
anyway and can still add the flag by hand.
I am therefore committing the attached patch.
Georg
Log:
Remove -mms-bitfields compiler option on windows, since all qt
releases that we support with the gcc toolchain on windows are
compiled without it.
Index: config/cygwin.m4
===
--- config/cygwin.m4 (Revision 13418)
+++ config/cygwin.m4 (Arbeitskopie)
@@ -5,35 +5,6 @@ AC_DEFUN([CHECK_WITH_CYGWIN],
[
case $host_os in
cygwin* | mingw* | pw32* )
-if test $GCC = yes; then
- # Ensure MSVC-compatible struct packing convention.
- # Depends on GCC version. gcc2 uses -fnative-struct while
- # gcc3 uses -mms-bitfields.
- #
- msnative_struct=''
- AC_MSG_CHECKING([how to get MSVC-compatible struct packing])
- case `$CC --version | sed -e 's,\..*,.,' -e q` in
- 2.)
-if $CC -v --help 2/dev/null | grep fnative-struct /dev/null; then
-msnative_struct='-fnative-struct'
-fi
-;;
- *)
-if $CC -v --help 2/dev/null | grep ms-bitfields /dev/null; then
-msnative_struct='-mms-bitfields'
-fi
-;;
- esac
-
- if test x$msnative_struct = x; then
-AC_MSG_RESULT([no way])
-AC_MSG_WARN([produced libraries might be incompatible with MSVC libs])
- else
-CXXFLAGS=$CXXFLAGS $msnative_struct
-AC_MSG_RESULT([${msnative_struct}])
- fi
-fi
-
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 version that Angus and I are using! Please be careful with what you are doing! I really need this option to be removed for the qt4 frontend when compiled with mingw. Why? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 it, and the default configuration of the Q..3/Windows Free Edition does not use this switch either. Therefore you and Angus have no choice and must use a libiconv that is compatible to this setting, too. The only possibility to use a libiconv that requires -mms-bitfields is to set this switch by hand when compiling qt yourself. In this case you can (and have to) set it by hand for LyX, too. If you know a way to detect the -mms-bitfields setting of qt automatically then I'll be happy to put code to do that in cygwin.m4. I really need this option to be removed for the qt4 frontend when compiled with mingw. Why? Because of crashes. Please read the whole thread. This has been discussed extensively. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 instruction. It was with the qt4 frontend Michael not qt2. The painting does not work at all when QWorkArea is compiled with -mms-bitfields. Something related to different memory models apparently. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. I am developing for Qt4 and for me patching it is out of the question. I will try again when I have some time. 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 directory having searched d:/msys/home/yns/lyx/trunk/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'. 2) I had to hack the source code in order to replace '/tmp' with 'c:/temp' because lyx tells me it cannot write the '/tmp' directory. Except for that I am happy to report that I cannot see any difference with the lyx I generated within MSYS. Except that the executable is smaller (12Mo instead of 19Mo) and that the compilation is faster. Enrico, if you have any hint for the problems above... Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. 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 change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Regards, Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 directory having searched
d:/msys/home/yns/lyx/trunk/share/lyx-svn/
Try the '-sysdir' command line parameter or set the environment variable
LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to ...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
2) I had to hack the source code in order to replace '/tmp' with
'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
Except for that I am happy to report that I cannot see any difference
with the lyx I generated within MSYS. Except that the executable is
smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
int
main ()
{
QApplication a(0,0);
a.unlock();
;
return 0;
}
fails compilation and a multi-threaded Qt would be not recognized
as such. I had to modify that program in the following way:
int
main ()
{
int argc;
char **argv = NULL;
QApplication a(argc,argv);
a.unlock();
;
return 0;
}
for the test to be successful in the case Qt is multi-threaded.
I think that's all. The native LyX I compile using cygwin is fully
functional and until now I have seen no side effects.
--
Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Angus, I suspect that this is an hardcoded path problem. The configure script sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale and then this directory is hardcoded into the executable. So, if LyX is installed in a different place than the $prefix dir, it will be unable to find the files. I don't know how this can be cleanly solved. I can think of two solutions. The first one is rather dirty: hack the configure script such that LYX_ABS_INSTALLED_LOCALEDIR is set to a PATH_MAX long string and then at installation time overwrite the string in the LyX executable with the proper path (other than dirty, this may also be fragile). The second one is the following. You already have an hardcoded path C:/Aspell, so you could change that to C:/LyXsupport and put there both aspell and locale files. A third possibility is investigating wheter libiconv/gettext support dynamic relocation. A fourth possibility is switching to cygwin and forget all those problems, but I suspect that this is not an option ;-) But, wait a moment... what about hacking configure such that LYX_ABS_INSTALLED_LOCALEDIR is a relative path? Uhm... perhaps that is not possible to do, I mean that perhaps it has to be an absolute path. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 that those libraries don't use -mms-bitfields, I think it is
> safe avoiding it. Moreover, if those libraries don't use -mms-bitfields
> and you enforce it, problems arise (see Abdel case).
I agree. If these libraries don't use -mms-bitfield then LyX must not use
it either. I had a look at the qt3 port for windows, and it does not use
it either in the default configuration for mingw and cygwin. So even if
we wanted to use other libraries that would require the switch we cannot
do so because qt3 does not use it.
Those who compile qt3 with nonstandard settings know what they are doing
anyway and can still add the flag by hand.
I am therefore committing the attached patch.
Georg
Log:
Remove -mms-bitfields compiler option on windows, since all qt
releases that we support with the gcc toolchain on windows are
compiled without it.
Index: config/cygwin.m4
===
--- config/cygwin.m4 (Revision 13418)
+++ config/cygwin.m4 (Arbeitskopie)
@@ -5,35 +5,6 @@ AC_DEFUN([CHECK_WITH_CYGWIN],
[
case $host_os in
cygwin* | mingw* | pw32* )
-if test "$GCC" = yes; then
- # Ensure MSVC-compatible struct packing convention.
- # Depends on GCC version. gcc2 uses -fnative-struct while
- # gcc3 uses -mms-bitfields.
- #
- msnative_struct=''
- AC_MSG_CHECKING([how to get MSVC-compatible struct packing])
- case `$CC --version | sed -e 's,\..*,.,' -e q` in
- 2.)
-if $CC -v --help 2>/dev/null | grep fnative-struct > /dev/null; then
-msnative_struct='-fnative-struct'
-fi
-;;
- *)
-if $CC -v --help 2>/dev/null | grep ms-bitfields > /dev/null; then
-msnative_struct='-mms-bitfields'
-fi
-;;
- esac
-
- if test x"$msnative_struct" = x; then
-AC_MSG_RESULT([no way])
-AC_MSG_WARN([produced libraries might be incompatible with MSVC libs])
- else
-CXXFLAGS="$CXXFLAGS $msnative_struct"
-AC_MSG_RESULT([${msnative_struct}])
- fi
-fi
-
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 version that Angus and I are using! Please be careful with what you are doing! I really need this option to be removed for the qt4 frontend when compiled with mingw. Why? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 it, and the default configuration of the Q..3/Windows Free Edition does not use this switch either. Therefore you and Angus have no choice and must use a libiconv that is compatible to this setting, too. The only possibility to use a libiconv that requires -mms-bitfields is to set this switch by hand when compiling qt yourself. In this case you can (and have to) set it by hand for LyX, too. If you know a way to detect the -mms-bitfields setting of qt automatically then I'll be happy to put code to do that in cygwin.m4. > > I really need this option to be removed for the qt4 frontend when > > compiled with mingw. > > Why? Because of crashes. Please read the whole thread. This has been discussed extensively. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 instruction. It was with the qt4 frontend Michael not qt2. The painting does not work at all when QWorkArea is compiled with -mms-bitfields. Something related to different memory models apparently. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. I am developing for Qt4 and for me patching it is out of the question. I will try again when I have some time. 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 directory having searched d:/msys/home/yns/lyx/trunk/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'. 2) I had to hack the source code in order to replace '/tmp' with 'c:/temp' because lyx tells me it cannot write the '/tmp' directory. Except for that I am happy to report that I cannot see any difference with the lyx I generated within MSYS. Except that the executable is smaller (12Mo instead of 19Mo) and that the compilation is faster. Enrico, if you have any hint for the problems above... Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. 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 change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Regards, Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 directory having searched
> d:/msys/home/yns/lyx/trunk/share/lyx-svn/
> Try the '-sysdir' command line parameter or set the environment variable
> LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'.
That also happened to me once, when I tried running LyX in place.
However, after installation I had no problems. If I remember correctly,
it was immediately after the switch from ...\Resources\lyx to ...\Resources
so, perhaps this is the case with you, too. If not, see below.
I don't see this problem anymore, so may be it was due to not updated
configuration files.
> 2) I had to hack the source code in order to replace '/tmp' with
> 'c:/temp' because lyx tells me it cannot write the '/tmp' directory.
>
> Except for that I am happy to report that I cannot see any difference
> with the lyx I generated within MSYS. Except that the executable is
> smaller (12Mo instead of 19Mo) and that the compilation is faster.
This may simply be due to the fact that mingw executables are to be
stripped. I don't see any significant difference in size between a
mingw and a cygwin LyX.
> Enrico, if you have any hint for the problems above...
Well, if '/tmp' is present in the source code, this is a bug with a
native LyX and you have no choice but replacing it with a proper path,
probably protecting the change using an #ifdef.
But it may be a configuration problem. All cygwin tools use posix syntax
by default, so care must be taken when generating Makefiles if they are
meant for building a native version of LyX.
For example, when invoking 'configure', you should use
--prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX,
but it is safe using --with-extra-prefix=/c/MinGW.
Another problem can arise when a path is autogenerated by configure.
There is some code in the configure script that turns 'C:/Programs/LyX'
into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your
settings), so I had to add the following to the sed command I use for
modifying configure:
# Set locale and data dir in mixed rather than posix format
/^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/
otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the
executable instead of 'C:/Programs/LyX/Resources/locale', and the net
effect would be that setting LANG to some locale doesn't work.
Thinking about it, perhaps this is the reason (hardcoded path) why
Angus reports that setting LANG seems not working in mingw builds.
However, this is the only problem that I spotted. To be honest there
was another one, but it was about the recognition of a multi-threaded
Qt. For some reason the default test program used in configure:
int
main ()
{
QApplication a(0,0);
a.unlock();
;
return 0;
}
fails compilation and a multi-threaded Qt would be not recognized
as such. I had to modify that program in the following way:
int
main ()
{
int argc;
char **argv = NULL;
QApplication a(argc,argv);
a.unlock();
;
return 0;
}
for the test to be successful in the case Qt is multi-threaded.
I think that's all. The native LyX I compile using cygwin is fully
functional and until now I have seen no side effects.
--
Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 change the installed .po (.gmo) dynamically to the local > locale. If I understood your message of some time ago correctly, you > reported that your essentially-identical cygwin build was able to display a > Polish LyX with native Windows LANG. > > When I read the libiconv/gettext build docs, it seems that the build > process is essentially circular. First build gettext, then libiconv, then > gettext again. (Or start with libiconv, then gettext, then libiconv again.) > > So, I suspect that my build doesn't work as advertised because my build is > incomplete. > > Before I invest time and effort into trying out my theory, can you explain > in more detail just what you did to get this stuff working? Angus, I suspect that this is an hardcoded path problem. The configure script sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale and then this directory is hardcoded into the executable. So, if LyX is installed in a different place than the $prefix dir, it will be unable to find the files. I don't know how this can be cleanly solved. I can think of two solutions. The first one is rather dirty: hack the configure script such that LYX_ABS_INSTALLED_LOCALEDIR is set to a PATH_MAX long string and then at installation time overwrite the string in the LyX executable with the proper path (other than dirty, this may also be fragile). The second one is the following. You already have an hardcoded path "C:/Aspell", so you could change that to "C:/LyXsupport" and put there both aspell and locale files. A third possibility is investigating wheter libiconv/gettext support dynamic relocation. A fourth possibility is switching to cygwin and forget all those problems, but I suspect that this is not an option ;-) But, wait a moment... what about hacking configure such that LYX_ABS_INSTALLED_LOCALEDIR is a relative path? Uhm... perhaps that is not possible to do, I mean that perhaps it has to be an absolute path. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 Windows without this, then I am all for removing it.
This is the case according to Enrico and Abdel. I am going to commit the
attached patch to trunk unless somebody objects.
Georg
Log:
Remove unneeded test for gcc2 on cygwin
Don't set -mms-bitfields on cygwin
Index: config/cygwin.m4
===
--- config/cygwin.m4 (Revision 13415)
+++ config/cygwin.m4 (Arbeitskopie)
@@ -4,36 +4,19 @@
AC_DEFUN([CHECK_WITH_CYGWIN],
[
case $host_os in
- cygwin* | mingw* | pw32* )
+ mingw* | pw32* )
if test $GCC = yes; then
# Ensure MSVC-compatible struct packing convention.
# Depends on GCC version. gcc2 uses -fnative-struct while
# gcc3 uses -mms-bitfields.
- #
- msnative_struct=''
- AC_MSG_CHECKING([how to get MSVC-compatible struct packing])
- case `$CC --version | sed -e 's,\..*,.,' -e q` in
- 2.)
-if $CC -v --help 2/dev/null | grep fnative-struct /dev/null; then
-msnative_struct='-fnative-struct'
-fi
-;;
- *)
-if $CC -v --help 2/dev/null | grep ms-bitfields /dev/null; then
-msnative_struct='-mms-bitfields'
-fi
-;;
- esac
-
- if test x$msnative_struct = x; then
-AC_MSG_RESULT([no way])
-AC_MSG_WARN([produced libraries might be incompatible with MSVC libs])
- else
-CXXFLAGS=$CXXFLAGS $msnative_struct
-AC_MSG_RESULT([${msnative_struct}])
- fi
+ # We support only gcc3.
+ CXXFLAGS=$CXXFLAGS -mms-bitfields
fi
+;;
+ esac
+ case $host_os in
+ cygwin* | mingw* | pw32* )
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Thanks, Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: Configuration Host type: i686-pc-cygwin Special build flags:compression use-aspell C Compiler: gcc -mno-cygwin C Compiler LyX flags: C Compiler flags: -I/c/MinGW/include -O2 C++ Compiler: g++ -mno-cygwin (3.4.4) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -I/c/MinGW/include -O2 Linker flags: Linker user flags: -L/usr/local/qt-win32/lib -lqt -lkernel32 -luser32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -limm32 -lwinmm -lwsock32 -lwinspool -L/c/MinGW/lib Qt Frontend: Qt version: 3.3.5 Packaging: windows LyX binary dir: C:/Programmi/LyX-1.4.0/bin LyX files dir: C:/Programmi/LyX-1.4.0/Resources Configuration of LyX was successful. Type 'make' to compile the program, and then 'make install' to install it. This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing ;-) -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. You're right... Why did you do that Georg? I was the one complaining about the option not the cygwin users... Could you please update your patch accordingly? However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: 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 executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. 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. 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. Do we have an m4 expert on the list? Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 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. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Sorry to be so pedantic here, but I really want to understand this issue before doing any change. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 not an m4 issue. Since several frontends can be built with --with-frontends='qt2 qt4 xforms' this would mean that parts of the code are compiled with -mms-bitfields and others without. That will for sure break things. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 compile Qt4, I used the official package for mingw. That's maybe the problem. I think we should support this official package. 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. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Well except for Qt4.1... Sorry to be so pedantic here, but I really want to understand this issue before doing any change. No problem. The safest solution is to modify the autotools for the qt4 subdir only. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 with -mms-bitfields. 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. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Sorry to be so pedantic here, but I really want to understand this issue before doing any change. Georg, I compile LyX with mingw as a target using cygwin. Cygwin has a minimal support for mingw as they use it only for compiling their setup.exe installation tool. Indeed, the only supported library is libz. 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. So, given that those libraries don't use -mms-bitfields, I think it is safe avoiding it. Moreover, if those libraries don't use -mms-bitfields and you enforce it, problems arise (see Abdel case). I think it is easier to add -mms-bitfields to CPPFLAGS (if needed) than hacking some m4 file or editing Makefiles to remove it. Anyway, that's my 2 cents... -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. I am developing for Qt4 and for me patching it is out of the question. I will try again when I have some time. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 Windows without this, then I am all for removing it.
This is the case according to Enrico and Abdel. I am going to commit the
attached patch to trunk unless somebody objects.
Georg
Log:
Remove unneeded test for gcc2 on cygwin
Don't set -mms-bitfields on cygwin
Index: config/cygwin.m4
===
--- config/cygwin.m4 (Revision 13415)
+++ config/cygwin.m4 (Arbeitskopie)
@@ -4,36 +4,19 @@
AC_DEFUN([CHECK_WITH_CYGWIN],
[
case $host_os in
- cygwin* | mingw* | pw32* )
+ mingw* | pw32* )
if test "$GCC" = yes; then
# Ensure MSVC-compatible struct packing convention.
# Depends on GCC version. gcc2 uses -fnative-struct while
# gcc3 uses -mms-bitfields.
- #
- msnative_struct=''
- AC_MSG_CHECKING([how to get MSVC-compatible struct packing])
- case `$CC --version | sed -e 's,\..*,.,' -e q` in
- 2.)
-if $CC -v --help 2>/dev/null | grep fnative-struct > /dev/null; then
-msnative_struct='-fnative-struct'
-fi
-;;
- *)
-if $CC -v --help 2>/dev/null | grep ms-bitfields > /dev/null; then
-msnative_struct='-mms-bitfields'
-fi
-;;
- esac
-
- if test x"$msnative_struct" = x; then
-AC_MSG_RESULT([no way])
-AC_MSG_WARN([produced libraries might be incompatible with MSVC libs])
- else
-CXXFLAGS="$CXXFLAGS $msnative_struct"
-AC_MSG_RESULT([${msnative_struct}])
- fi
+ # We support only gcc3.
+ CXXFLAGS="$CXXFLAGS -mms-bitfields"
fi
+;;
+ esac
+ case $host_os in
+ cygwin* | mingw* | pw32* )
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Thanks, Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 think this was related to trying to compile for QT/Cygwin. If we can > >> compile for QT on Windows without this, then I am all for removing it. > > > > This is the case according to Enrico and Abdel. I am going to commit the > > attached patch to trunk unless somebody objects. > > Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: Configuration Host type: i686-pc-cygwin Special build flags:compression use-aspell C Compiler: gcc -mno-cygwin C Compiler LyX flags: C Compiler flags: -I/c/MinGW/include -O2 C++ Compiler: g++ -mno-cygwin (3.4.4) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -I/c/MinGW/include -O2 Linker flags: Linker user flags: -L/usr/local/qt-win32/lib -lqt -lkernel32 -luser32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -limm32 -lwinmm -lwsock32 -lwinspool -L/c/MinGW/lib Qt Frontend: Qt version: 3.3.5 Packaging: windows LyX binary dir: C:/Programmi/LyX-1.4.0/bin LyX files dir: C:/Programmi/LyX-1.4.0/Resources Configuration of LyX was successful. Type 'make' to compile the program, and then 'make install' to install it. This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing ;-) -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. You're right... Why did you do that Georg? I was the one complaining about the option not the cygwin users... Could you please update your patch accordingly? However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: 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 executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
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 linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Michael
