Building GTK apps for MS Windows on Linux

Windows 10安装MySQL8.0.15 失败,提示This application requires Visual Studio 2015 x64 Redistributable.解决办法 Windows 10安装MySQL8.0.15 失败,提示This application requires Visual Studio 2015 x64 Redistributable.解决办法 目录: 一:错误提示 二:解决办法 一:错误提示: 1: Action 22:47:16: INSTALL. 1: 1: MySQL Server 8.0 2: {28176271-5414-47DD-... 阅读详情

Building GTK apps for MS Windows on Linux

Contents

Cross-compiler and binutils
Win32 API
GTK API for win32
GTK pkgconfig files
Configuring and building sources for win32
DLL-building magic
Simple makefile example
GTK runtime files
Message catalogs
Creating a self-installing exe

Introduction

The intended readership for this page is those who are already quite comfortable with building GTK-based software on Linux (who know their way around the various tools), and who wish to prepare win32 versions of their programs without having to mess with that Other OS themselves.

I don't have time at present to write a full, coherent HOWTO. What you'll find here are various ideas, tips and examples in a fairly raw state. They are based on my experience in cross-building for Windows my program gretl. If you want to take a look at a fairly large-scale example of a cross build, grab the gretl source package from sourceforge and poke around in the win32 subdirectory of the source.

Since some elements below may date fairly quickly, I should say that I'm writing this in early October, 2004. I'm sure to have overlooked various details in these notes: if anyone spots missing stuff, please let me know and I'll update this page. If you find this page of interest, you might also want to take a look at my page on using some native win32 stuff in a GTK context.

Cross-compiler and binutils

Your first requirement is a cross-compiler and an appropriate set of binutils (as, ld and friends).

You can assemble these yourself or there is the option of grabbing a cross-compiler package (in binary or source form) from libsdl.org.

If you take the put-it-together-yourself route (as I have done), I recommend starting your shopping at mingw.org. Take a look at the mingw download area and decide how adventurous you want to be ("Candidate" releases of various vintages or the "Current" release). Download the source for selected releases of binutils and gcc. I am currently using gcc version 3.4.0 and binutils version 2.15.90, and they work fine.

Now you need to decide on a location for your cross system. I put it in /opt/cross-tools. Having chosen a place to install the tools, configure and make them. I use these scripts:

#!/bin/sh
cd binutils-whatever
mkdir build
cd build
../configure --disable-nls --target=mingw32 /
--prefix=/opt/cross-tools --disable-shared
make  "CFLAGS=-O2 -fno-exceptions" "LDFLAGS=-s"
make install
#!/bin/sh
cd gcc-whatever
mkdir build
cd build
../configure --target=mingw32 --prefix=/opt/cross-tools --disable-nls /
 --disable-shared --enable-languages=c,c++,f77 
make CFLAGS="-O2 -fomit-frame-pointer" LDFLAGS=-s
make install

You can probably throw away the documentation for these tools, since you'll already have it for the Linux versions:

rm -rf /opt/cross-tools/info /opt/cross-tools/man

or something like that.

Win32 API

To get any further you need to install the appropriate headers and import libraries to support the win32 API. As of this writing, the package you want is w32api-3.1.tar.gz (again, from mingw.org). Untar the package in the appropriate place. For example if you've chosen /opt/cross-tools for your cross tools root, and you've configured gcc with a target of mingw32, your cross-gcc will be found in /opt/cross-tools/mingw32 and you'd do, e.g.

cd /opt/cross-tools/mingw32
tar xvfz w32api-3.1.tar.gz

GTK API for win32

It's a GTK app you're building, so you need all the appropriate headers and import libs. You could (perhaps) build all that stuff yourself, but why bother when Tor Lillqvist has done the job for us? [If you do feel like trying this, check out the documentation for Cross-compiling the GLib package.]

Pick up all the current "dev" zipfiles (atk, glib, gtk, pango) from Tor's download page. Tor also offers links to win32 versions of various GTK dependencies, such as libiconv, libpng, zlib and libxml2. You'll want to grab these too. In all cases you need the "dev" files, containing headers and the "import libraries" (*.a or *.lib) that are needed at compile time. If you want to package and distribute a GTK runtime along with your app (making it self-contained), you'll also need to grab the corresponding "bin" or "runtime" packages. These contain the dlls corresponding to the import libraries, along with various other runtime files (see below for details on this).

I recommend unzipping the GTK and associated "dev" files using the same root as mentioned above for the win32 API. That is, import libs go into /opt/cross-tools/mingw32/lib on my system, and headers are based at /opt/cross-tools/mingw32/include.

Note on import libraries: You're likely to run across more than one variety of import library. There are *.a libs, which work nicely with a cross gcc. Tor's packages include these. But some packages don't include *.a libraries, only Microsoft-style *.lib files. These can be used OK with the utility mingw32-dllwrap, but not (so far as I can tell) directly with cross gcc. On the other hand, you may find that if the .lib files don't work (linker errors) you can substitute the corresponding dlls and get linking to work.

GTK pkgconfig files

The pkgconfig files supplied with Tor's GTK "dev" packages are designed for use on Windows and have to be modified slightly for a cross build (so that they contain the correct prefix). Here is a script that does the job (to be run in the relevant cross pkgconfig directory) :

#!/bin/sh

TARGET=/opt/cross-tools/mingw32

for f in *.pc ; do
   if grep 'prefix=/target' $f >/dev/null 2>&1 ; then
     cat $f | sed s+^prefix=/target+prefix=$TARGET+ > $f.tmp
     mv $f.tmp $f
   fi
done  

Configuring and building sources for win32

For cross-building your own app, or for cross-building special dependencies (extra dlls), there are broadly two approaches:

  1. Use the regular mechanism of configure scripts in conjunction with pkg-config, but in cross mode.

  2. Use hand-crafted Makefiles.

The first option is preferable if it works OK. Obviously you're going to need some environment variable magic to get anything working. Having experimented a bit, I now start by sourcing the following (source cross.env).

# cross.env
PREFIX=/opt/cross-tools
TARGET=mingw32
export CC="mingw32-gcc -mms-bitfields"
export CXX="mingw32-g++ -mms-bitfields"
export CFLAGS="-O2 -march=i586 -mms-bitfields"
export CXXFLAGS="-O2 -march=i586 -mms-bitfields"
export PKG_CONFIG_PATH=$PREFIX/$TARGET/lib/pkgconfig
export PATH=$PREFIX/bin:$PREFIX/$TARGET/bin:/bin:/usr/bin
export LD_LIBRARY_PATH=$PREFIX/$TARGET/lib
export LDFLAGS=-L$PREFIX/$TARGET/lib
export OBJDUMP=$PREFIX/bin/mingw32-objdump
export HOST_CC=/usr/bin/gcc

Note: The -mms-bitfields flag is essential if you want your app to actually run on win32 (when using Tor Lillqvist's pre-built GTK runtime at any rate).

In place of plain configure I use this script called cross-configure:

#!/bin/sh

TARGET=mingw32
cache=win32.cache
sh configure --cache-file="$cache" /
        --target=$TARGET --host=$TARGET --build=i686-linux /
        --prefix=/opt/cross-tools/mingw32 $*
status=$?
rm -f "$cache"
exit $status

With the environment set up correctly, make can be used as is (no fancy stuff required).

Note: An alternative to the above approach is to load all the required environment settings into your cross-configure script, and write a corresponding cross-make script that invokes make with the appropriate environment. Advantage of this alternative: you don't need to "pollute" your working environment with all the cross-compilation settings, as happens when you source cross.env. Disadvantage: it's easy to forget what you're doing and type make when you mean cross-make, which results in a big mess.

Whichever variant of the "cross-configure" approach you employ, you may run into problems building dlls. For some reason libtool (I'm currently using version 1.5.10) does not seem to want to make Windows dlls on Linux (I can get static libraries OK). There are several "issues" here -- I'm gradually coming to understand them, but I don't have a sure fix at this point. [Update October 6, 2004: Making a bit more progress -- details here.]

In the meantime, I tend to resort the following…

DLL-building magic

Here's a sample of a Makefile that "works for me" for cross-building dlls (this one makes a dll out of the Cephes library code for figuring probability-values). If I get stuck using other methods I copy-n-paste from this and modify as needed.

CC = mingw32-gcc -Wall -O2 -mms-bitfields
AS = mingw32-as
DLLWRAP = mingw32-dllwrap

CFLAGS = -I.

PROBSRC = bdtr.c btdtr.c chdtr.c drand.c expx2.c fdtr.c gamma.c gdtr.c /
	igam.c igami.c incbet.c incbi.c mtherr.c nbdtr.c ndtr.c ndtri.c /
        pdtr.c stdtr.c unity.c polevl.c const.c

PROBOBJ = $(PROBSRC:.c=.o)

%.o: %.c
	$(CC) -c $(CFLAGS) ___FCKpd___7lt;

DLLWRAP_FLAGS = --as=$(AS) --export-all --driver-name $(CC) -s

# build libprob.dll, and create a corresponding import library
# libprob.a

libprob.dll: $(PROBOBJ) 
	$(DLLWRAP) $(DLLWRAP_FLAGS) /
	--output-def libprob.def --implib libprob.a /
	-o $@ $^ 

The routine is: make all the object files as usual, then package them into a dll using mingw32-dllwrap. If you need additional libraries linked in, stick them onto the end of the dllwrap command, as in:

libgretl.dll: $(LIBOBJ) $(MINOBJ) 
        $(DLLWRAP) $(DLLWRAP_FLAGS) /
        --output-def libgretl.def --implib libgretl.a /
        -o $@ $^ -lf2c -lm -L$(imports) -lxml2 -lz -lintl -lprob -lgmp /
        -lmingwex $(GLIBLIB) $(LAPACK_LIBS)

Simple makefile example

Here's an example of a complete cross-Makefile for a trivial GTK program. Note the compiler flag -mwindows: this is required to produce a windows application as opposed to a win32 console application (which automatically spawns a console when invoked via a menu or icon).

CC = mingw32-gcc -O2 -Wall -mms-bitfields -mwindows
PKG_CONFIG_PATH = /opt/cross-tools/mingw32/lib/pkgconfig

CFLAGS := $(shell PKG_CONFIG_PATH=$(PKG_CONFIG_PATH) /
          pkg-config --cflags gtk+-win32-2.0)
LIBS := $(shell PKG_CONFIG_PATH=$(PKG_CONFIG_PATH) /
          pkg-config --libs gtk+-win32-2.0)

foo.exe: foo.c
        $(CC) -o $@ $(CFLAGS) ___FCKpd___9lt; $(LIBS)

GTK runtime files

By "GTK runtime files" I mean the set of DLLs, modules, configuration files and message catalogs that support the actual execution of a GTK program.

When you distribute a GTK application for Linux, it's natural to assume that the GTK runtime will already be in place -- or if it's not, that the user will be able to install it easily from packages such as rpms or debs. It's not your responsibility as an application developer to provide the basic runtime.

On MS Windows, of course, GTK is not part of the basic kit and you face a choice:

  • Tell users that your package depends on the GTK runtime, and point them towards a third-party package containing that runtime.

  • Package with your app that portion of the GTK runtime that the app requires, thereby making your package self-contained.

If you decide on the first option you may want to take a look at the GTK installers offered by Alex Shaduri and Jernej Simoncic.

I have gone for the second option: I prefer to give users the simplest possible one-step installation. If you take this approach you will probably want to find out what is the minimal subset of GTK runtime files required to support your application. You will surely need all the basic DLLs for atk, glib, gtk and pango, plus their essential dependencies such as zlib, libxml2, libiconv and libintl. You'll need some of the dynamically-loadable modules for gtk and pango, but probably not all of them. You may or may not need message catalogs for gtk and friends. It may take a bit of trial and error to figure out the essential subset.

For reference, I show below a listing of the GTK runtime files that I distribute with my application. The path to these files is relative to the installation directory chosen by the user at install time (see Creating a self-installing exe below).

The GPL:

COPYING

Core GTK DLLs:

libatk-1.0-0.dll
libgdk_pixbuf-2.0-0.dll
libgdk-win32-2.0-0.dll
libglib-2.0-0.dll
libgmodule-2.0-0.dll
libgobject-2.0-0.dll
libgthread-2.0-0.dll
libgtk-win32-2.0-0.dll
libpango-1.0-0.dll
libpangoft2-1.0-0.dll
libpangowin32-1.0-0.dll

Basic dependency DLLs:

iconv.dll
intl.dll
libpng12.dll
libxml2.dll
zlib1.dll

Basic config files:

etc/pango/pango.modules
etc/pango/pango.aliases
etc/gtk-2.0/gdk-pixbuf.loaders
etc/gtk-2.0/gtkrc

Image-file loaders (subset for the image formats used by my app):

lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.dll
lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.dll

Message catalogs (subset for the languages supported by my app):

lib/locale/es/LC_MESSAGES/atk10.mo
lib/locale/es/LC_MESSAGES/glib20.mo
lib/locale/es/LC_MESSAGES/gtk20.mo
lib/locale/fr/LC_MESSAGES/atk10.mo
lib/locale/fr/LC_MESSAGES/glib20.mo
lib/locale/fr/LC_MESSAGES/gtk20.mo
lib/locale/it/LC_MESSAGES/atk10.mo
lib/locale/it/LC_MESSAGES/glib20.mo
lib/locale/it/LC_MESSAGES/gtk20.mo
lib/locale/ja/LC_MESSAGES/glib20.mo
lib/locale/ja/LC_MESSAGES/gtk20.mo
lib/locale/pl/LC_MESSAGES/glib20.mo
lib/locale/pl/LC_MESSAGES/gtk20.mo

Pango modules (subset: my app only supports European languages):

lib/pango/1.4.0/modules/pango-basic-win32.dll
lib/pango/1.4.0/modules/pango-basic-fc.dll

"WIMP" support (optional: let the user make the app look more Windows-like):

etc/gtk-2.0/gtkrc.wimp
lib/gtk-2.0/2.4.0/engines/libwimp.dll

Message catalogs for your application

If your app is internationalized, you'll want to make binary message catalogs (.mo) in win32 format. I do this by using msgfmt.exe (available in the GNU gettext package for win32) under wine.

Creating a self-installing exe

Yes, you can even do this without leaving Linux -- with a little help from wine. Jordan Russell makes available a nice free installer-builder, Inno Setup. It's a Windows program, but it runs fine on Linux under wine (its own self-installer works fine under wine too.) It is fully scriptable and its compiler can be run non-interactively.

In case you're interested, here is a sample script, gretl.iss, for use with Inno Setup.


Allin Cottrell <cottrell@wfu.edu>

Last modified: Wed Oct 6, 2004

转自:http://www.ecn.wfu.edu/~cottrell/cross-gtk/

无影云电脑部署OpenClaw:环境一致性与服务持久性实践指南 云原生AI工具链的稳定运行,首先依赖可复现、可运维的标准化执行环境。OpenClaw作为面向钉钉与百炼API的自动化智能网关,其核心挑战不在模型调用本身,而在于底层运行时一致性(如Node.js 22+、glibc版本、动态链接库路径)与服务长周期存活能力。本地终端因系统碎片化(GTK主题冲突、输入法混用、休眠中断)难以满足7×24小时网关监听需求;而无影云电脑提供预置验证的Alibaba Cloud Linux镜像、快照回滚机制及云监控集成,天然适配OpenClaw对环境固化与心跳保活的强要求。本文聚焦无 阅读详情

相关推荐

Linux】【shell】常用命令全称

Shell 命令全称与含义详解

qq_45800521的博客 183

Electron: To build app for Windows on Linux

参考:https://www.electron.build/multi-platform-build Docker(electronuserland/builder:wine) is recommended to avoid installing system dependencies. ...

chuzhong5401的博客 1185

ObservableList

普通的List是“数据容器”,而是“数据源 + 广播电台”。添加的功能:监听器、精准变更报告、原子替换、实时过滤/排序视图。本质区别普通List是被动的(你问它才给)。是主动的(它变了就立刻告诉你,并且告诉你“哪里变了、怎么变的”)。正是因为它具备了这种“主动广播”的能力,JavaFX 才能实现数据驱动 UI的响应式编程模型。你之前在ComboBox源码中看到的监听器,正是依赖的机制才得以生效的。

qq_24992377的博客 411

Windows 7 x64环境下JDK8安装过程

Windows 7 x64环境下JDK8安装过程 下载地址:http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html 最好是不要使用默认的目录,通常默认的目录都带有空格,可能会引起不必要的麻烦; ...

weixin_33834137的博客 348

RustDesk 1.4.6 客户端编译环境搭建&官方安装版完整编译教程(Windows 11)

已测试,1.4.6版本rustdesk编译环境搭建

qq_34337638的博客 550

使用playonlinux安装windows软件

转载 http://qspy.is-programmer.com/posts/40913.html Wine提供了一个用来运行Windows程序的平台。PlayOnLinux 是使用 Python 写成的Wine图形化前端。本篇幅主要介绍 PlayOnLinux 的用法。 因为图片太多,上传太麻烦,所以本文是无图版的;如果有需要全文连图片的,请告诉我,我会发出来。 软件介绍 wine ...

weixin_33943347的博客 1049

Running Windows 10 on Linux using KVM with VGA Passthrough

https://heiko-sieger.info/running-windows-10-on-linux-using-kvm-with-vga-passthrough virtual machines on a Linux host platform without compromising performance of the (Windows) guest system. For some benchmarks of my current system, see Windows 10 Virtual

JL-LOVE 9681

elasticsearch安装 及 启动异常解决

虚拟机使用net连接模式 1 Download and unzip the latest Elasticsearch distribution 2 Run bin/elasticsearch on Unix or bin\elasticsearch.bat on Windows 3 Run curl -X GET http://localhost:9200/ 官网 :www.elasti...

happyzxs的博客 6万+

windows subsystem on linux安装步骤

为了在win下更好的使用Linux操作,安装bash,操作如下:1 以管理员方式运行power shell2 执行以下命令Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux可以参照官网3重启计算机4 在{设置→更新和安全}里面打开{针对开发人员模式}5 打开bash按照提示输入yes

小草莓的博客 928

使用easyexcel导出数据

使用EasyExcel 2.1.4实现自定义监听器,校验表头(去除换行空格)及数据行:转换实体,检查组合代码/类型、计划类型非空且合法,收集错误信息,返回有效数据列表。

feng_huilu_zhuan的博客 265

@Value 详解:Spring 属性注入的核心注解

Value是 Spring 中最基础的配置注入注解,适合注入少数配置项或需要 SpEL 表达式的场景。当配置项较多且结构复杂时,是更好的选择。理解@Value的解析机制(处理${}处理#{}),有助于排查配置不生效和类型转换错误。

weixin_51288065的博客 476

06-05-排序集合-综合对比-SortedSet-vs-SortedDictionary-vs-SortedList选型

<think>我们根据要求,生成一篇不超过150字的文章摘要。内容是关于SortedSet、SortedDictionary与SortedList的选择指南。需要提取核心要点:根据语义选择类型,树型与数组型实现差异,注意比较器、可变键、性能与内存,以及实验验证。摘要应精炼。</think>摘要:比较SortedSet、SortedDictionary与SortedList,应优先按语义选择:唯一元素用Set,键值映射按更新模式选Dictionary或List,后者支持位置索引。注意比

设计 AI 玩游戏🎮 794

Kubernetes 认证和授权:从身份认证到权限控制实战

创建 clusterrole 名称 cluster-pod-deploy-reader,能够查看pod和deployment赋予给 shaka 用户shaka 用户在 auth 命名空间中:查看pod、deploymentshaka 用户在 kube-system 命名空间中:查看pod、deployment删除集群角色绑定和集群角色Service Account,即服务账户,pod 使用 Service Account 身份运行容器。

2603_94950994的博客 279

Guava——集合(一)

它解决了原生 Java 中 Map<K, List> 或 Map<K, Set> 维护繁琐的问题(如手动初始化集合、判空、移除元素等),将一个键对应多个值的逻辑封装为统一且简洁的接口。com.google.common.collect.BiMap 是 Guava 提供的双向映射(Bi-directional Map)接口。它继承自 Java 标准的 java.util.Map,核心特点是保证 键(Key)和值(Value)的双向唯一性。

吴声子夜歌的博客 397
上一篇: QT实现跨平远程控制程序
下一篇: SOA Frequently Asked Questions
forlinux
博客等级 码龄20年 53粉丝 95原创
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值