Quantcast

static library file names and wx-config in case of cross-compilation linux->windows

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
Hi,

When cross-compiling from linux->windows, I get for example the
following library in lib:
  libwx_baseu-3.1-x86_64-w64-mingw32.a
but wx-config --libs says
  /softs/win64-mingw-6.3.0/release/wx/lib/libwx_baseu_xml-3.1.a
so without x86_64-w64-mingw32 triplet. Full list below.

This is annoying but I wrote a python script to change that. However I
realize that this will not work when configuring wxpdfdocument which
calls wx-config directly. Is there any way to change this strange
behaviour?

I say 'strange' because when I cross-build wx linux->darwin, the
triplet is present in the wx-config --libs output:
  /softs/osx64-clang-3.9.1/release/wx/lib/libwx_baseu_xml-3.1-x86_64-apple-darwin13.a

Frédéric

$ ls lib
libwx_baseu-3.1-x86_64-w64-mingw32.a
libwx_baseu_net-3.1-x86_64-w64-mingw32.a
libwx_baseu_xml-3.1-x86_64-w64-mingw32.a
libwxexpat-3.1-x86_64-w64-mingw32.a
libwx_mswu_adv-3.1-x86_64-w64-mingw32.a
libwx_mswu_aui-3.1-x86_64-w64-mingw32.a
libwx_mswu_core-3.1-x86_64-w64-mingw32.a
libwx_mswu_gl-3.1-x86_64-w64-mingw32.a
libwx_mswu_html-3.1-x86_64-w64-mingw32.a
libwx_mswu_propgrid-3.1-x86_64-w64-mingw32.a
libwx_mswu_qa-3.1-x86_64-w64-mingw32.a
libwx_mswu_ribbon-3.1-x86_64-w64-mingw32.a
libwx_mswu_richtext-3.1-x86_64-w64-mingw32.a
libwx_mswu_stc-3.1-x86_64-w64-mingw32.a
libwxregexu-3.1-x86_64-w64-mingw32.a
libwxscintilla-3.1-x86_64-w64-mingw32.a

$ wx-config --libs
-Wl,--subsystem,windows -mwindows
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_qa-3.1.a
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_html-3.1.a
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_adv-3.1.a
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_core-3.1.a
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_baseu_xml-3.1.a
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_baseu-3.1.a -lpng -ljpeg
-ltiff -lwxregexu-3.1-x86_64-w64-mingw32
-lwxexpat-3.1-x86_64-w64-mingw32 -lz -lrpcrt4 -loleaut32 -lole32
-luuid -llzma -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32
-lcomdlg32 -ladvapi32 -lversion -lwsock32 -lgdi32

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Sun, 26 Mar 2017 06:31:16 +0200 Frédéric Bron wrote:

FB> When cross-compiling from linux->windows, I get for example the
FB> following library in lib:
FB>   libwx_baseu-3.1-x86_64-w64-mingw32.a
FB> but wx-config --libs says
FB>   /softs/win64-mingw-6.3.0/release/wx/lib/libwx_baseu_xml-3.1.a
FB> so without x86_64-w64-mingw32 triplet. Full list below.

 I can't actually reproduce this here: if I run configure with
--host=i686-w64-mingw32 option on my Debian system I get
-lwx_baseu-3.1-i686-w64-mingw32 in wx-config output. And if I add
--disable-shared option, then I get $full_path_to/
libwx_baseu-3.1-i686-w64-mingw32.a

 What configure options exactly do you use to see this problem?
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
>  I can't actually reproduce this here: if I run configure with
> --host=i686-w64-mingw32 option on my Debian system I get
> -lwx_baseu-3.1-i686-w64-mingw32 in wx-config output. And if I add
> --disable-shared option, then I get $full_path_to/
> libwx_baseu-3.1-i686-w64-mingw32.a
>
>  What configure options exactly do you use to see this problem?

* Here is the command I use:

./configure
--prefix=/softs/win64-mingw-6.3.0/release/wx
--host=x86_64-w64-mingw32
--disable-shared
--enable-cxx11 --enable-stl ...
--with-msw
--enable-optimise --disable-debug

* Here are the libraries I get (all marked with the triplet):
libwx_baseu-3.1-x86_64-w64-mingw32.a
libwx_baseu_net-3.1-x86_64-w64-mingw32.a
libwx_baseu_xml-3.1-x86_64-w64-mingw32.a
libwxexpat-3.1-x86_64-w64-mingw32.a
libwx_mswu_adv-3.1-x86_64-w64-mingw32.a
libwx_mswu_aui-3.1-x86_64-w64-mingw32.a
libwx_mswu_core-3.1-x86_64-w64-mingw32.a
libwx_mswu_gl-3.1-x86_64-w64-mingw32.a
libwx_mswu_html-3.1-x86_64-w64-mingw32.a
libwx_mswu_propgrid-3.1-x86_64-w64-mingw32.a
libwx_mswu_qa-3.1-x86_64-w64-mingw32.a
libwx_mswu_ribbon-3.1-x86_64-w64-mingw32.a
libwx_mswu_richtext-3.1-x86_64-w64-mingw32.a
libwx_mswu_stc-3.1-x86_64-w64-mingw32.a
libwxregexu-3.1-x86_64-w64-mingw32.a
libwxscintilla-3.1-x86_64-w64-mingw32.a

* Here is the output of wx-config --libs (triplet for -l options, no
triplet for library file name option):
-L/softs/win64-mingw-6.3.0/release/wx/lib
-L/softs/win64-mingw-6.3.0/release/iconv/lib
-L/softs/win64-mingw-6.3.0/release/gettext/lib
-L/softs/win64-mingw-6.3.0/release/bzip2/lib
-L/softs/win64-mingw-6.3.0/release/zlib/lib
-L/softs/win64-mingw-6.3.0/release/jpeg-turbo/lib
-L/softs/win64-mingw-6.3.0/release/xz/lib
-L/softs/win64-mingw-6.3.0/release/tiff/lib
-L/softs/win64-mingw-6.3.0/release/png/lib
-L/softs/win64-mingw-6.3.0/release/sqlite/lib
-Wl,--subsystem,windows
-mwindows
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_qa-3.1.a -> missing triplet
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_html-3.1.a -> missing triplet
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_adv-3.1.a -> missing triplet
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_mswu_core-3.1.a -> missing triplet
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_baseu_xml-3.1.a -> missing triplet
/softs/win64-mingw-6.3.0/release/wx/lib/libwx_baseu-3.1.a -> missing triplet
-lpng
-ljpeg
-ltiff
-lwxregexu-3.1-x86_64-w64-mingw32 -> OK
-lwxexpat-3.1-x86_64-w64-mingw32 -> OK
-lz
-lrpcrt4
-loleaut32
-lole32
-luuid
-llzma
-lwinspool
-lwinmm
-lshell32
-lshlwapi
-lcomctl32
-lcomdlg32
-ladvapi32
-lversion
-lwsock32
-lgdi32

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[2]: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Sat, 1 Apr 2017 19:49:35 +0200 Frédéric Bron wrote:

FB> >  I can't actually reproduce this here: if I run configure with
FB> > --host=i686-w64-mingw32 option on my Debian system I get
FB> > -lwx_baseu-3.1-i686-w64-mingw32 in wx-config output. And if I add
FB> > --disable-shared option, then I get $full_path_to/
FB> > libwx_baseu-3.1-i686-w64-mingw32.a
FB> >
FB> >  What configure options exactly do you use to see this problem?
FB>
FB> * Here is the command I use:
FB>
FB> ./configure

 First note: you really, really shouldn't run configure in the source
directory. This does work, if you're very careful, but it's very simple to
get mysterious problems if you are not and I wonder if you're not running
into one of them. At least with git you can always do "git clean -dfx" to
remove all the build files and make sure you can restart from a clean
slate, but it's even better to avoid making a mess in the source directory
in the first place and create a separate build directory for your build and
running configure from there.

FB> --prefix=/softs/win64-mingw-6.3.0/release/wx
FB> --host=x86_64-w64-mingw32
FB> --disable-shared
FB> --enable-cxx11 --enable-stl ...
FB> --with-msw
FB> --enable-optimise --disable-debug

 Second note is to not use --disable-debug while developing, even for the
cross-builds that you're unlikely to debug (although gdb does work under
MSW too). You may get MSW-specific assert failures pointing to something
wrong in your code that you wouldn't get under Linux, but by using
--disable-debug you suppress them and, again, increase the probability of
running into mysterious problems.

FB> * Here is the output of wx-config --libs (triplet for -l options, no
FB> triplet for library file name option):

 I just can't reproduce this here, after running the same commands, e.g. I
get:

% /usr/local/bin/wx-config --libs
-L/usr/local/lib   -Wl,--subsystem,windows -mwindows /usr/local/lib/libwx_mswu_xrc-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_qa-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_baseu_net-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_html-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_adv-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_mswu_core-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_baseu_xml-3.1-i686-w64-mingw32.a /usr/local/lib/libwx_baseu-3.1-i686-w64-mingw32.a -lwxregexu-3.1-i686-w64-mingw32 -lwxexpat-3.1-i686-w64-mingw32 -lwxtiff-3.1-i686-w64-mingw32 -lwxjpeg-3.1-i686-w64-mingw32 -lwxpng-3.1-i686-w64-mingw32 -lwxzlib-3.1-i686-w64-mingw32 -lrpcrt4 -loleaut32 -lole32 -luuid -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32 -lcomdlg32 -ladvapi32 -lversion -lwsock32 -lgdi32 -loleacc

This is for 32 bit build, but I reran configure for x86_64 host and did
"./wx-config --libs" (i.e. without installing it, as this would require
building the library which I don't really need) and it returns the correct
paths too.


 So my advice would be:

1. Check that you're using the latest git master.
2. Clean your source directory using "git clean" (do verify you don't lose
   any important files with "git status" first, of course!).
3. Create a separate build directory and try rebuilding from there.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
>  First note: you really, really shouldn't run configure in the source
> directory. This does work, if you're very careful, but it's very simple to
> get mysterious problems if you are not and I wonder if you're not running
> into one of them.

done that with 3.1.0 and latest git -> no change.

>  Second note is to not use --disable-debug while developing, even for the
> cross-builds that you're unlikely to debug (although gdb does work under
> MSW too). You may get MSW-specific assert failures pointing to something
> wrong in your code that you wouldn't get under Linux, but by using
> --disable-debug you suppress them and, again, increase the probability of
> running into mysterious problems.

This is just an example, I always build 2 versions, one release and
one debug. I get the same issue with both.

>  So my advice would be:
>
> 1. Check that you're using the latest git master.

done -> no change

> 2. Clean your source directory using "git clean" (do verify you don't lose
>    any important files with "git status" first, of course!).

no issue, I used git archive to make a tarball.

> 3. Create a separate build directory and try rebuilding from there.

done -> no change


>  I just can't reproduce this here, after running the same commands, e.g. I
> get:
> % /usr/local/bin/wx-config --libs

One idea: can you build with a --prefix option different from /usr/local?
I wonder if wx-config is not searching something in the system
directory even if --prefix is set to something different.

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[4]: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Sun, 2 Apr 2017 21:10:53 +0200 Frédéric Bron wrote:

FB> >  So my advice would be:
FB> >
FB> > 1. Check that you're using the latest git master.
FB>
FB> done -> no change
FB>
FB> > 2. Clean your source directory using "git clean" (do verify you don't lose
FB> >    any important files with "git status" first, of course!).
FB>
FB> no issue, I used git archive to make a tarball.

 Building multiple versions of the library in the same source directory can
easily confuse the makefiles, so it's not about making tarballs or anything
like this. In brief, building directly in the source tree is acceptable as
a quick way to build the library once only, but not for any repeated
builds.

FB> > 3. Create a separate build directory and try rebuilding from there.
FB>
FB> done -> no change

 I'm really out of ideas here...

FB> >  I just can't reproduce this here, after running the same commands, e.g. I
FB> > get:
FB> > % /usr/local/bin/wx-config --libs
FB>
FB> One idea: can you build with a --prefix option different from /usr/local?

 I don't see how could this change anything, but I'm so lost that I tried
it just in case and it still works just fine here (wrapped for convenience):

% ~/tmp/root/bin/wx-config --libs
-L/home/zeitlin/tmp/root/lib   -Wl,--subsystem,windows -mwindows
/home/zeitlin/tmp/root/lib/libwx_mswu_xrc-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_mswu_qa-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_baseu_net-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_mswu_html-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_mswu_adv-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_mswu_core-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_baseu_xml-3.1-i686-w64-mingw32.a
/home/zeitlin/tmp/root/lib/libwx_baseu-3.1-i686-w64-mingw32.a
-lwxregexu-3.1-i686-w64-mingw32 -lwxexpat-3.1-i686-w64-mingw32
-lwxtiff-3.1-i686-w64-mingw32 -lwxjpeg-3.1-i686-w64-mingw32
-lwxpng-3.1-i686-w64-mingw32 -lwxzlib-3.1-i686-w64-mingw32 -lrpcrt4
-loleaut32 -lole32 -luuid -lwinspool -lwinmm -lshell32 -lshlwapi -lcomctl32
-lcomdlg32 -ladvapi32 -lversion -lwsock32 -lgdi32 -loleacc

 Moreover, I even built another, native build of wxWidgets and installed it
into the same directory hoping that I can reproduce the problem like this,
but I still couldn't, "~/tmp/root/bin/wx-config --host=i686-w64-mingw32
--libs" works correctly (--host option is needed because the native build
has become the default now, as it was installed last) and outputs the same
thing as before. And if I reinstall the cross-build again, it rebecomes the
default and still gives the same output when called without any --host
option.

 BTW, what does "wx-config --list" return for you? Also, does it still
misbehave if you run it directly as "./wx-config --libs" from the build
directory instead of running the installed version?

 Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[4]: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
> FB> > 2. Clean your source directory using "git clean" (do verify you don't lose
> FB> >    any important files with "git status" first, of course!).
> FB>
> FB> no issue, I used git archive to make a tarball.
>
>  Building multiple versions of the library in the same source directory can
> easily confuse the makefiles, so it's not about making tarballs or anything
> like this. In brief, building directly in the source tree is acceptable as
> a quick way to build the library once only, but not for any repeated
> builds.

I never build two versions in the same directory. I always starts in a
new directory but now I also build outside the source directory.

>  Moreover, I even built another, native build of wxWidgets and installed it
> into the same directory hoping that I can reproduce the problem like this,
> but I still couldn't, "~/tmp/root/bin/wx-config --host=i686-w64-mingw32
> --libs" works correctly (--host option is needed because the native build
> has become the default now, as it was installed last) and outputs the same
> thing as before. And if I reinstall the cross-build again, it rebecomes the
> default and still gives the same output when called without any --host
> option.

This is interesting, because I have already tried to add --host to
wx-config and I get an error:
$ /softs/win64-mingw-6.3.0/release/wx/bin/wx-config --host=x86_64-w64-mingw32

 *** Error: Bad config delegation

 to: /softs/win64-mingw-6.3.0/release/wx/lib/wx/config/x86_64-w64-mingw32-msw-unicode-static-3.1
 (msw-unicode-static-3.1) cannot satisfy:
 /softs/win64-mingw-6.3.0/release/wx/lib/wx/config/x86_64-w64-mingw32-msw-unicode-static-3.1
--host=x86_64-w64-mingw32
 Someone has been terribly careless.

>  BTW, what does "wx-config --list" return for you?

$ /softs/win64-mingw-6.3.0/release/wx/bin/wx-config --list

    Default config is msw-unicode-static-3.1

  Default config will be used for output
  though it is not installed in: /softs/win64-mingw-6.3.0/release/wx

  Also available in /softs/win64-mingw-6.3.0/release/wx:
    x86_64-w64-mingw32-msw-unicode-static-3.1


> Also, does it still
> misbehave if you run it directly as "./wx-config --libs" from the build
> directory instead of running the installed version?

same issue.

One thing maybe: I am using my own cross-compiler stored in
/softs/mingw64-6.3.0/bin/x86_64-w64-mingw32-g++ and I also have one
from fedora in
/usr/bin/x86_64-w64-mingw32-g++... I do not see what this could change but...

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[6]: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Mon, 3 Apr 2017 07:06:28 +0200 Frédéric Bron wrote:

FB> This is interesting, because I have already tried to add --host to
FB> wx-config and I get an error:
FB> $ /softs/win64-mingw-6.3.0/release/wx/bin/wx-config --host=x86_64-w64-mingw32
FB>
FB>  *** Error: Bad config delegation
FB>
FB>  to: /softs/win64-mingw-6.3.0/release/wx/lib/wx/config/x86_64-w64-mingw32-msw-unicode-static-3.1
FB>  (msw-unicode-static-3.1) cannot satisfy:
FB>  /softs/win64-mingw-6.3.0/release/wx/lib/wx/config/x86_64-w64-mingw32-msw-unicode-static-3.1
FB> --host=x86_64-w64-mingw32
FB>  Someone has been terribly careless.
FB>
FB> >  BTW, what does "wx-config --list" return for you?
FB>
FB> $ /softs/win64-mingw-6.3.0/release/wx/bin/wx-config --list
FB>
FB>     Default config is msw-unicode-static-3.1
FB>
FB>   Default config will be used for output
FB>   though it is not installed in: /softs/win64-mingw-6.3.0/release/wx
FB>
FB>   Also available in /softs/win64-mingw-6.3.0/release/wx:
FB>     x86_64-w64-mingw32-msw-unicode-static-3.1

 OK, so something is clearly wrong with the "host" option detection for
this wx-config. Looking at wx-config, it depends on the values of
"cross_compiling" and "host_alias" determined by configure, so could you
please post the output of "egrep '(cross_compiling|host_alias)' config.status"
in your build directory?

FB> One thing maybe: I am using my own cross-compiler stored in
FB> /softs/mingw64-6.3.0/bin/x86_64-w64-mingw32-g++ and I also have one
FB> from fedora in
FB> /usr/bin/x86_64-w64-mingw32-g++... I do not see what this could change but...

 As long as you use --host option to configure instead of specifying CXX,
CC, LD and other tools directly, it should still work...

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[6]: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
>  OK, so something is clearly wrong with the "host" option detection for
> this wx-config. Looking at wx-config, it depends on the values of
> "cross_compiling" and "host_alias" determined by configure, so could you
> please post the output of "egrep '(cross_compiling|host_alias)' config.status"
> in your build directory?

S["cross_compiling"]="no"
S["host_alias"]="i686-w64-mingw32"

> FB> One thing maybe: I am using my own cross-compiler stored in
> FB> /softs/mingw64-6.3.0/bin/x86_64-w64-mingw32-g++ and I also have one
> FB> from fedora in
> FB> /usr/bin/x86_64-w64-mingw32-g++... I do not see what this could change but...
>
>  As long as you use --host option to configure instead of specifying CXX,
> CC, LD and other tools directly, it should still work...

In fact I use both because I want to be sure configure uses "my"
compiler and not another cross-compiler with the same name. Is this
the cause of all this?

My full command line is:
CC="i686-w64-mingw32-gcc-6.3.0" CFLAGS="-O2 -DNDEBUG"
CXX="i686-w64-mingw32-g++-6.3.0" CXXFLAGS="-O2 -DNDEBUG -std=gnu++14"
CPPFLAGS="-I/softs/win32-mingw-6.3.0/release/iconv/include
-I/softs/win32-mingw-6.3.0/release/gettext/include
-I/softs/win32-mingw-6.3.0/release/bzip2/include
-I/softs/win32-mingw-6.3.0/release/zlib/include
-I/softs/win32-mingw-6.3.0/release/jpeg-turbo/include
-I/softs/win32-mingw-6.3.0/release/xz/include
-I/softs/win32-mingw-6.3.0/release/tiff/include
-I/softs/win32-mingw-6.3.0/release/png/include
-I/softs/win32-mingw-6.3.0/release/sqlite/include"
LDFLAGS="-L/softs/win32-mingw-6.3.0/release/iconv/lib
-L/softs/win32-mingw-6.3.0/release/gettext/lib
-L/softs/win32-mingw-6.3.0/release/bzip2/lib
-L/softs/win32-mingw-6.3.0/release/zlib/lib
-L/softs/win32-mingw-6.3.0/release/jpeg-turbo/lib
-L/softs/win32-mingw-6.3.0/release/xz/lib
-L/softs/win32-mingw-6.3.0/release/tiff/lib
-L/softs/win32-mingw-6.3.0/release/png/lib
-L/softs/win32-mingw-6.3.0/release/sqlite/lib"
AR="i686-w64-mingw32-ar" AS="i686-w64-mingw32-as"
RANLIB="i686-w64-mingw32-ranlib"  LIBS=" -llzma "
/softs/win32-mingw-6.3.0/release/build/wxWidgets-e9ce55e/configure
--prefix=/softs/win32-mingw-6.3.0/release/wx --host=i686-w64-mingw32
--disable-shared --enable-cxx11 --enable-stl --enable-intl
--disable-permissive --disable-compat28 --disable-compat30
--disable-protocols --disable-ftp --disable-http --disable-fileproto
--disable-sockets --disable-ipv6 --disable-ipc --disable-protocol
--disable-protocol-http --disable-protocol-ftp --disable-protocol-file
--disable-precomp-headers --disable-url --disable-mediactrl
--disable-webkit --disable-webview --disable-epollloop --with-cxx=14
--disable-xrc --with-libpng --with-libjpeg --with-libtiff
--with-liblzma --with-libiconv-prefix=/softs/win32-mingw-6.3.0/release/iconv
--with-zlib-include-dir=/softs/win32-mingw-6.3.0/release/zlib/include
--with-zlib-lib-dir=/softs/win32-mingw-6.3.0/release/zlib/lib
--with-msw --enable-optimise --disable-debug

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[8]: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Mon, 3 Apr 2017 14:36:53 +0200 Frédéric Bron wrote:

FB> >  OK, so something is clearly wrong with the "host" option detection for
FB> > this wx-config. Looking at wx-config, it depends on the values of
FB> > "cross_compiling" and "host_alias" determined by configure, so could you
FB> > please post the output of "egrep '(cross_compiling|host_alias)' config.status"
FB> > in your build directory?
FB>
FB> S["cross_compiling"]="no"

 OK, that's the root of the problem.

FB> >  As long as you use --host option to configure instead of specifying CXX,
FB> > CC, LD and other tools directly, it should still work...
FB>
FB> In fact I use both because I want to be sure configure uses "my"
FB> compiler and not another cross-compiler with the same name. Is this
FB> the cause of all this?

 Yes, clearly, although I *still* can't reproduce this :-( But at least
this should give you a workaround: instead of doing what you do, you should
rename (or create links to) your 6.3 compiler to not use "-6.3.0" suffix
and then run

PATH=/softs/mingw64-6.3.0/bin:$PATH .../configure --host=i686-w64-mingw32 ...

and cross-compiling should be detected correctly.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[8]: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
> FB> >  OK, so something is clearly wrong with the "host" option detection for
> FB> > this wx-config. Looking at wx-config, it depends on the values of
> FB> > "cross_compiling" and "host_alias" determined by configure, so could you
> FB> > please post the output of "egrep '(cross_compiling|host_alias)' config.status"
> FB> > in your build directory?
> FB>
> FB> S["cross_compiling"]="no"
>
>  OK, that's the root of the problem.


I found something that may help:
In config.log I have what is given below.

I guess that configure tries to compile a small program and to run it
to see if some result can be found in some output file or in the
terminal.
Because I have wine installed, the windows program is executed as if
it were a native program so I guess that configure finds an output
instead of a program failure.

Frédéric


configure:12850: checking whether we are cross compiling
configure:12858: i686-w64-mingw32-gcc-6.3.0 -o conftest.exe -O2
-DNDEBUG -I/softs/win32-mingw-6.3.0/release/iconv/include
-I/softs/win32-mingw-6.3.0/release/gettext/include
-I/softs/win32-mingw-6.3.0/release/bzip2/include
-I/softs/win32-mingw-6.3.0/release/zlib/include
-I/softs/win32-mingw-6.3.0/release/jpeg-turbo/include
-I/softs/win32-mingw-6.3.0/release/xz/include
-I/softs/win32-mingw-6.3.0/release/tiff/include
-I/softs/win32-mingw-6.3.0/release/png/include
-I/softs/win32-mingw-6.3.0/release/sqlite/include
-L/softs/win32-mingw-6.3.0/release/iconv/lib
-L/softs/win32-mingw-6.3.0/release/gettext/lib
-L/softs/win32-mingw-6.3.0/release/bzip2/lib
-L/softs/win32-mingw-6.3.0/release/zlib/lib
-L/softs/win32-mingw-6.3.0/release/jpeg-turbo/lib
-L/softs/win32-mingw-6.3.0/release/xz/lib
-L/softs/win32-mingw-6.3.0/release/tiff/lib
-L/softs/win32-mingw-6.3.0/release/png/lib
-L/softs/win32-mingw-6.3.0/release/sqlite/lib conftest.c  -llzma  >&5
configure:12862: $? = 0
configure:12869: ./conftest.exe
fixme:winediag:start_process Wine Staging 2.4 is a testing version
containing experimental patches.
fixme:winediag:start_process Please mention your exact version when
filing bug reports on winehq.org.
configure:12873: $? = 0
configure:12888: result: no

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[10]: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Mon, 3 Apr 2017 15:04:11 +0200 Frédéric Bron wrote:

FB> > FB> >  OK, so something is clearly wrong with the "host" option detection for
FB> > FB> > this wx-config. Looking at wx-config, it depends on the values of
FB> > FB> > "cross_compiling" and "host_alias" determined by configure, so could you
FB> > FB> > please post the output of "egrep '(cross_compiling|host_alias)' config.status"
FB> > FB> > in your build directory?
FB> > FB>
FB> > FB> S["cross_compiling"]="no"
FB> >
FB> >  OK, that's the root of the problem.
FB>
FB>
FB> I found something that may help:
FB> In config.log I have what is given below.
FB>
FB> I guess that configure tries to compile a small program and to run it
FB> to see if some result can be found in some output file or in the
FB> terminal.
FB> Because I have wine installed, the windows program is executed as if
FB> it were a native program so I guess that configure finds an output
FB> instead of a program failure.

 Oh, yes, absolutely, I didn't think about this at all, but it explains the
problem perfectly (and so it as nothing to do, finally, with specifying the
cross-compiler explicitly, forget my advice in the previous reply).

 To really fix this, just add --build=x86_64-unknown-linux-gnu to configure
command line, this should disable this automatic "is cross-compiling"
detection and just assume that you're, indeed, cross-compiling.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[10]: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
> FB> I guess that configure tries to compile a small program and to run it
> FB> to see if some result can be found in some output file or in the
> FB> terminal.
> FB> Because I have wine installed, the windows program is executed as if
> FB> it were a native program so I guess that configure finds an output
> FB> instead of a program failure.
>
>  Oh, yes, absolutely, I didn't think about this at all, but it explains the
> problem perfectly (and so it as nothing to do, finally, with specifying the
> cross-compiler explicitly, forget my advice in the previous reply).
>
>  To really fix this, just add --build=x86_64-unknown-linux-gnu to configure
> command line, this should disable this automatic "is cross-compiling"
> detection and just assume that you're, indeed, cross-compiling.


Bingo, it works!

And this explains why I did not have the issue cross-compiling to OSX
(no wine equivalent).

Thanks a lot.

There is still something strange with wx-config but it do not need to
be fixed for me: why did it add the triplet for -llibs and not for
/path/to/lib.a?

Cheers,

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[12]: static library file names and wx-config in case of cross-compilation linux->windows

Vadim Zeitlin-4
On Mon, 3 Apr 2017 15:25:32 +0200 Frédéric Bron wrote:

FB> There is still something strange with wx-config but it do not need to
FB> be fixed for me: why did it add the triplet for -llibs and not for
FB> /path/to/lib.a?

 Do you mean that shared libraries names were correct, even when
cross_compiling ended up being set to "no"? If so, I'm not really sure and
it's a bit difficult to debug as I don't have Wine set up to run MSW
programs automatically.

 In any case, the real problem is definitely relying on automatic cross
compilation detection and using --build explicitly helps with this, so this
is good enough for me...

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[12]: static library file names and wx-config in case of cross-compilation linux->windows

Frédéric Bron
> FB> There is still something strange with wx-config but it do not need to
> FB> be fixed for me: why did it add the triplet for -llibs and not for
> FB> /path/to/lib.a?
>
>  Do you mean that shared libraries names were correct, even when
> cross_compiling ended up being set to "no"? If so, I'm not really sure and

They are not shared but some of them appear with -llib option while
others appear with /path/to/lib.a
The -llib where OK with the triplet.

The 2 that appear with -llib are:
-lwxregexu-3.1-i686-w64-mingw32
-lwxexpat-3.1-i686-w64-mingw32

>  In any case, the real problem is definitely relying on automatic cross
> compilation detection and using --build explicitly helps with this, so this
> is good enough for me...

yes, it works now, that is just fine.
Thanks,
Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Loading...