Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#13054 closed defect (wontfix)

Unresolved GdipStringFormatCachedGeneric in MSys Configure build Using MinGW GCC on Trunk

Reported by: stahta01 Owned by:
Priority: normal Milestone: 2.9.2
Component: build Version: stable-latest
Keywords: MSYS Cc:
Blocked By: Blocking:
Patch: no

Description

See Also http://trac.wxwidgets.org/changeset/66787
See http://trac.wxwidgets.org/ticket/11716

Modified patch from above by adding
(defined(GNUWIN32) && defined(WX_SETUP_H))

I have no idea if the defined(CYGWIN) is still needed.

Tim S.

Attachments (1)

wxWidgets-trunk-SJLJ.patch download (1.1 KB) - added by stahta01 3 years ago.
MSYS Build Fiz

Download all attachments as: .zip

Change History (8)

Changed 3 years ago by stahta01

MSYS Build Fiz

comment:1 follow-up: Changed 3 years ago by vadz

  • Milestone set to 2.9.2

Why is the check for __WX_SETUP_H_ needed, wouldn't the same problem occur when building for MinGW using makefiles?

comment:2 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by stahta01

Replying to vadz:

Why is the check for __WX_SETUP_H_ needed, wouldn't the same problem occur when building for MinGW using makefiles?

I just built wxWidgets using MinGW makefiles and it compiled without error. I am now trying to use the same options when using MSys Configure.
(I used Monolithic with MinGW makefiles; "USE_QA=1 USE_STC=0 USE_OPENGL=1 BUILD=release UNICODE=1 MONOLITHIC=1 SHARED=1").
I am trying MSys Configure with --enable-monolithic to see if that is the cause.

Tim S

comment:3 in reply to: ↑ 2 ; follow-up: Changed 3 years ago by stahta01

Replying to stahta01:

Replying to vadz:

Why is the check for __WX_SETUP_H_ needed, wouldn't the same problem occur when building for MinGW using makefiles?

I just built wxWidgets using MinGW makefiles and it compiled without error. I am now trying to use the same options when using MSys Configure.
(I used Monolithic with MinGW makefiles; "USE_QA=1 USE_STC=0 USE_OPENGL=1 BUILD=release UNICODE=1 MONOLITHIC=1 SHARED=1").
I am trying MSys Configure with --enable-monolithic to see if that is the cause.

Tim S

Oops, just realized I used a different version of MinGW GCC for each build will need to try again.

Tim S.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by stahta01

Replying to stahta01:

Replying to stahta01:

Replying to vadz:

Why is the check for __WX_SETUP_H_ needed, wouldn't the same problem occur when building for MinGW using makefiles?

I just built wxWidgets using MinGW makefiles and it compiled without error. I am now trying to use the same options when using MSys Configure.
(I used Monolithic with MinGW makefiles; "USE_QA=1 USE_STC=0 USE_OPENGL=1 BUILD=release UNICODE=1 MONOLITHIC=1 SHARED=1").
I am trying MSys Configure with --enable-monolithic to see if that is the cause.

Tim S

Oops, just realized I used a different version of MinGW GCC for each build will need to try again.

Tim S.

It has finished building without error using MinGW GCC makefile.gcc using the exact same compiler as used by MSys config; still waiting on MSys config monolithic build to finish.

Tim S.

comment:5 in reply to: ↑ 4 Changed 3 years ago by stahta01

Why is the check for __WX_SETUP_H_ needed, wouldn't the same problem occur when building for MinGW using makefiles?

It has finished building without error using MinGW GCC makefile.gcc using the exact same compiler as used by MSys config; still waiting on MSys config monolithic build to finish.

Tim S.

MSys config failed again; found out why it did not fail with makefile.gcc build; because setup.h define wxUSE_GRAPHICS_CONTEXT as zero.

I have decided that wxUSE_GRAPHICS_CONTEXT most likely should be zero for now with Cygwin and MSys configure builds. The w32api headers are just not close enough to work. Trying --disable-graphics_ctx with configure to get a good build.

Feel free to close this ticket.

Tim S.

comment:6 follow-up: Changed 3 years ago by vadz

  • Resolution set to wontfix
  • Status changed from new to closed

Pity that wxGC still can't be used with MinGW, it really is becoming a big problem but unfortunately it doesn't look like there is anything we can do about it.

comment:7 in reply to: ↑ 6 Changed 3 years ago by catalin

Replying to vadz:

Pity that wxGC still can't be used with MinGW

FWIW there are some headers that can be downloaded from here which can be used with gcc for adding GDI+ support. They just need to be added in the include path. Compilation should be ok with gcc 3.4.x, but throws 2 easy to fix errors with gcc 4.x.x which are described here.
And also set wxUSE_GRAPHICS_CONTEXT=1 in setup.h.

Everything is built with mingw gcc and makefile.gcc. The drawing sample has Use GraphicContext menu option and runs fine.

wxW is pre-2.9.2 with a recent trunk update; Win7.

Note: See TracTickets for help on using tickets.