这个固件是在Toastman-RT-N cf33364的基础上手动加入ASUS新版固件中的5.100.138.20驱动后编译的，测试了半个多月基本稳定，然后看待还没人放出5.100.138.20驱动的整合版，于是我就放一个我编译的版本，make的参数是r2e，含vpn。下载
mingw 编译gcc 4.7.0 遇到的问题
gcc 4.7.0 发布有几天了，前几天试着编译了一下。中间遇到了一个问题，在这里说明一下，希望在编译gcc 4.7.0遇到同样问题且看到我这篇文章的问有帮助。 继续阅读
mingw mpfr 3.1.0 make check failed
mpfr 3.1.0出来有一阵了，但是在mingw下编译make check一直失败，找不到原因。今天看了下官方发现从3.1.0开始mpfr支持TLS线程安全，然后说明上说可能和部分平台及编译器不兼容，于是抱着试一下的心情加上–disable-thread-safe的配置参数后meke check通过了。不过不清楚详细原因，可能跟gcc有关吧。
Windows平台下php session设置导致的问题
下午刚回家就有人报告45s服务器老是500，于是爬上去看了下。发现php老重启，于是把iis重启了一下。接着顺手把mysql也重启了一下，这一重启把mysql搞得再起不能了= =。半天没搞懂为什么。后来把系统也重启了还是没法恢复，mysql错误日志和windows系统日志都看不出问题，mysql启动后就卡住了。
没办法。打开万能的Process Monitor，这才发现mysql在不断的读取C:\Windows\Temp下的文件，且文件名都是sess_开头的，这才发现是php session搞的鬼。本来以前php的session保存目录都被设置在php自身目录下的tmp目录中的，但是上次更新php后iis 的php manager自动给设回C:\Windows\Temp了。没办法用del sess_*来删除这些session文件。然后重设的php及mysql的配置。
php设置参考了php session.save_path设置中的N值设置来优化磁盘性能，结合从php源码目录中的ext/session下找到的mod_files.bat来辅助生成session子目录。mod_files.bat的参数如下
Usage mod_files.bat <basedir> <depth> [hash_bits]
Where <basedir> is the session directory
<depth> is the number of levels defined in session.save_path
[hash_bits] is the number of bits defined in session.hash_bits_per_character
php默认配置session.hash_bits_per_character为5，我打算把N设为3，于是输入”mod_files.bat tmppath 3 5“来生成session的临时文件目录。然后相应的把php配置文件中的session.save_path值改成”3;tmppath“，上面2处的tmppath为选择的session存储路径，建议php配置文件中用绝对路径。
mysql则在配置文件中的[mysqld]下添加了tmpdir的配置，在mysql所在目录新建了一个temp文件夹然后把tmpdir的值指向了那个目录。
至此问题解决了
当ipv6遇上google analytics
把路由用tomato开启ipv6隧道已经有一段时间了，除了速度慢点外勉强还算可以用。不过最近一直觉得45s打开很慢，但是在服务器上可以秒开，跟踪了几次都没发现原因。但是今天偶然发现是ipv6引起的。由于google的所有地址都通过hosts指定为ipv6地址了，且google analytics的地址也是ipv6的，而45s刚好又启用了google analytics。不过今天登陆了一下google analytics发现界面更新了，而且还推出了异步跟踪代码。于是马上把45s的分析代码给替换了，然后立刻秒开了(^_^)
坑爹的柯南OVA11
昨天终于把柯南OVA11看了。发现被宣传画给其骗了，只有开头部分的哀酱菜可爱啊，化妆后的哀和步美都是那么的黑人＞＜真使坑爹啊。再说这剧情，是不是太无聊了一点===
ffdshow-tryout中ffmpeg 用gcc-4.5.2 x64编译失败原因
前段时间一直折腾64位ffdshow-tryout，唯独ffmpeg始终无法编译成功，链接的时候出现一堆undefined reference。但是其他软件都能正常编译运行。后来看了ffdshow-tryout的官方编译用的gcc-4.4.4，于是我从x264官方用的64位gcc的网站找了个64位的gcc-4.4.5和gcc-4.5.2来测试，发现gcc-4.5.2依然链接失败，但是gcc-4.4.5却可以成功。于是打算自己编译gcc-4.4.5的64位，但又遇到问题，用自己电脑上的gcc-4.5.2交叉编译的64位gcc-4.4.5完全无法用。没办法于是用komisar的gcc-4.4.5来交叉编译，一路很顺利，直到编译译完mingw-w64 crt后，在编译libgcc时configure都失败。看看config.log依然是链接失败，crt中一堆undefined reference。没办法，尝试自己编译了32位的gcc-4.4.5，再交叉编译，问题依旧。之后发现komisar的gcc都是用的static编译，随即我也将gcc配置成static，libgcc算是编译成功了，但之后的lib则依然出现undefined reference。在无计可施的情况下，google了一堆东西，终于在一个网站上找到一点资料
You can use the binutils-cvs with gcc 4.4 series if you configure binutils with --enable-leading-mingw64-underscores You can build gcc 4.5 and 4.6 against older versions of binutils (or binutils built with --enable-leading-mingw64-underscores) with the same option during gcc's configure.
由于我用的binutils是最新的snapshot，于是我加上–enable-leading-mingw64-underscores重新编译一次，之后重新编译了crt和libgcc，终于正常了。后来仔细搜索了一下enable-leading-mingw64-underscores的资料，发现俄罗斯的视频技术网站XvidVideo.RU上的ffdshow-tryout是用gcc-4.5.3编译的，然后该网站提供的gcc均加上了–enable-leading-mingw64-underscores的参数，看来我电脑上ffmpeg链接失败应该是这个原因，于是又重新编译了一次gcc-4.5.2，终于ffdshow能够正常编译了。总的来说应该是mingw64符号前缀变化导致的一系列问题。但是官方wiki编译指南并没有说明。
写在离开APTX4869字幕组
不知不觉中已经在字幕组混了6-7年了，当年因为帮朋友下载柯南的动画而接触了 APTX4869 字幕组，而后又因为对EVA的热爱成立了EVA-FANS，最然这个名字感觉很老土。而后又在各位大大的提拔下进入了45s，成为分流组的主力，继而主管发布，偶然的机会接手了一段时间的rmvb压制进而进入了字幕组。大学毕业之后又因为2部Slayer TV版的关系混入了POPGO。之后又由于种种原因解散了EVA-FANS成立了NES，当然EVA-FANS的目标基本达成。以上便是我在字幕组到目前为止的生涯。在这期间认识了很多人，也学会了不少的东西，算是对业余爱好的充实吧。但毕竟年龄大了，没有办法投入太多的精力在这上面，毕竟在大陆没办法把这方面的爱好作为职业，所以也是时候收手了。完成了柯南剧场版14的压制，也就完成了我在45s最后一个愿望，压一次BDRIP。虽然几经周折，但还是很满足了，这也是我第一次把一部剧场版压了5回的片子，不过应该也是最后一次了。离开字幕组后难免还是会有些伤感，不过这还不是最后，接下来的工作是EVA的几部新剧场版。当完成这些后，我就正式告别字幕界，专心做一名看客～
