从cygwin/windows的角度来看，xffm(这里指4.2版本)的代码模块化方面可谓混乱之极, xffm可执行文件和一堆共享库相互依赖，这在Windows下是不允许的。这就使得xffm-4.2非常难以移植到cygwin上来。
但今天终于再此搞定了，虽然费了整整一天。(但我还是更喜欢用rox)
大致的方法如下:
- 将smb模块和将libs目录下的库编译为静态库
- 将xffm与上述模块进行链接，得到xffm.exe, 用dlltool 输出(export)xffm.exe的全部public符号
- modules下的模块全部依赖于xffm.exe
依赖于libs目录下的一堆库，这些库当中又有引用xffm中的符号的情况；smb模块似乎是可以不编译的，但
libs目录下面的那些库偏偏又用到了smb可加载情况下才有的一些功能；另外modules目录学唉还有一堆插件，实现书签、回收站等虚拟文件系统；
xfdiff4这个小功能也需要libs目录下的libxffm_secondary里面的一些函数。
因为windows下不允许一个可执行文件或者动态库中包含未定义的符号, 所以需要仔细界定一个函数或者变量是在哪里实现，所以从4.1.90版本开始一直搞不定这个东西的移植，每次开始折腾一会儿就晕了。
仔细琢磨了一下代码结构，发掘其实也蛮简单，将原来libs下面的共享库变成静态库不就行了?
但这样的大调整，仅仅靠修改Makefile.in不禁会繁死，而且还很难成功，因为有些东西(比如将编译动态库改为编译静态库，因为用了libtool这些东西)靠修改Makefile.in不知道怎么下手。
于是我从Makefile.am下手，运气好的是，用automake重新生成Makefile.in很顺利，并没有用到什么目前cygwin下面没有的宏。
源代码补丁正在整理中，过两天就可以上载到主页上去了。
The xffm executable used some symbols defined in the libraries in
directory `libs', but these libs also reference some symbols defined
in the xffm executable; the smb module seems to be loadable, for
supporting some systems that don't have smb support , but the libraries
in `libs' insist to call some functions implmented in smb module.
As Windows doesn't allow undefined symbols in the executable and shared
libraries, thus we should know exactly where a symbols is implemented.
Starting from version 4.1.90 of xffm, I neven succeed in porting xffm
to cygwin. Every time I started to work on it, I would be confused and
disoriented just in a few minutes.
I
walked through the code structure, suddenly the God shed some lights on
me: why not just build those libraries into static ones and link xffm
to them?
Then I tried, works! (This change requires me to hacked the Makefile.ams. I'm not familar with
automake/autoconf. But fortunately enough, I got no any error when
running automake.)
Now I'm examining the modification to got a source patch. Maybe you can see it on my repository in a few days.
但今天终于再此搞定了，虽然费了整整一天。(但我还是更喜欢用rox)
大致的方法如下:
- 将smb模块和将libs目录下的库编译为静态库
- 将xffm与上述模块进行链接，得到xffm.exe, 用dlltool 输出(export)xffm.exe的全部public符号
- modules下的模块全部依赖于xffm.exe
From the viewpoint of cygwin/windows, the module structure of xffm-4.2 is a whole mass. The xffm executable and a pack of shared libraries used each other's symbols, which is not allowed on
cygwin/windows. This made it very hard to port xffm-4.2 to cygwin.
But now xffm (4.2) is back to cygwin! I spent a whole day on this. (Nevertheless I'd prefer rox to xffm).
- Turn the libraries in directory `libs' into static libraries
- Link xffm against the libraries above and then we have xffm.exe. Use dlltool to export all the public symbols of xffm.exe.
- Link the modules in directory `modules' against xffm.exe.
依赖于libs目录下的一堆库，这些库当中又有引用xffm中的符号的情况；smb模块似乎是可以不编译的，但
libs目录下面的那些库偏偏又用到了smb可加载情况下才有的一些功能；另外modules目录学唉还有一堆插件，实现书签、回收站等虚拟文件系统；
xfdiff4这个小功能也需要libs目录下的libxffm_secondary里面的一些函数。
因为windows下不允许一个可执行文件或者动态库中包含未定义的符号, 所以需要仔细界定一个函数或者变量是在哪里实现，所以从4.1.90版本开始一直搞不定这个东西的移植，每次开始折腾一会儿就晕了。
仔细琢磨了一下代码结构，发掘其实也蛮简单，将原来libs下面的共享库变成静态库不就行了?
但这样的大调整，仅仅靠修改Makefile.in不禁会繁死，而且还很难成功，因为有些东西(比如将编译动态库改为编译静态库，因为用了libtool这些东西)靠修改Makefile.in不知道怎么下手。
于是我从Makefile.am下手，运气好的是，用automake重新生成Makefile.in很顺利，并没有用到什么目前cygwin下面没有的宏。
源代码补丁正在整理中，过两天就可以上载到主页上去了。
The xffm executable used some symbols defined in the libraries in
directory `libs', but these libs also reference some symbols defined
in the xffm executable; the smb module seems to be loadable, for
supporting some systems that don't have smb support , but the libraries
in `libs' insist to call some functions implmented in smb module.
As Windows doesn't allow undefined symbols in the executable and shared
libraries, thus we should know exactly where a symbols is implemented.
Starting from version 4.1.90 of xffm, I neven succeed in porting xffm
to cygwin. Every time I started to work on it, I would be confused and
disoriented just in a few minutes.
I
walked through the code structure, suddenly the God shed some lights on
me: why not just build those libraries into static ones and link xffm
to them?
Then I tried, works! (This change requires me to hacked the Makefile.ams. I'm not familar with
automake/autoconf. But fortunately enough, I got no any error when
running automake.)
Now I'm examining the modification to got a source patch. Maybe you can see it on my repository in a few days.
没有评论:
发表评论