wget -O pxe-ne2k_pci.bin http://svn.savannah.gnu.org/viewvc/*checkout*/trunk/pc-bios/pxe-ne2k_pci.bin?root=qemu
wget -O pxe-rtl8139.bin http://svn.savannah.gnu.org/viewvc/*checkout*/trunk/pc-bios/pxe-rtl8139.bin?root=qemu
wget -O pxe-e1000.bin http://svn.savannah.gnu.org/viewvc/*checkout*/trunk/pc-bios/pxe-e1000.bin?root=qemu
sudo mv pxe*.bin /usr/share/qemu/

二月二十八日 当前只有等待等待

trent.josephsen, over the last 2 days, I have put in a lot of effort trying to understand so's. I have understood most of the things. I have a few questions, however.

1. Is it possible to append to /etc/ld.so.cache from "any random dir/user specified dir" by doing ldconfig? I tried doing ldconfig -n . , but that doesn't seem to work.

2. Which are the directories on which ldconfig operates ? Are they, a)everything mentioned in /etc/ld.so.conf.d/*.conf + b)/lib + c)/usr/lib ?

3. Don't you think all paths in the makefile should also be added to the list of dir's an "so" is searched in ? That would take away the overhead of adding paths where so's exist to LD_LIBRARY_PATH since these are already mentioned at build time. Why mention them again at runtime ? EDIT:probably, /etc/ld.so.conf should have a file like fromMakefile.conf

4. I copied an "so" to /usr/lib/i386-linux-gnu and was able to run the file, WITHOUT doing an ldconfig. Is that because
a) since it is under /usr/lib, it will run even if it doesn't figure in /etc/ld.so.cache OR
b) all directories under /etc/ld.so.conf.d/*.conf are manually searched for so's if it is not found in the cache?

5. I find the output of ldconfig lacking information about which "realname" it is currently running. I understand it will be something like libname.so.MAJOR.LATESTMINOR, but ldconfig doesn't tell me which one is the latest.

6. I don't understand why ldconfig should hold information of this nature.
libname.so.1 ==> /usr/lib/i386-linux-gnu/libname.so.1
According to me libname.so ==> /usr/lib/i386-linux-gnu/libname.so is sufficient.
I mean, the user would only enter something like -lname. so as long as information about libname.so is maintained, all others can be found through soft links.

EDIT : adding 3 more questions

7.Why do we mention the major number part also in the realname ? I mean it's confusing someone could make an so like, $gcc -shared -Wl,-soname,libname.so.33 -o libname.so.1.14 lib.o. I mean in the actual SONAME field, the soname would be libname.so.33, but someone looking at the libname.so.1.14 alone would think it is libname.so.1.

8.Don't you think finding the latest minor number which belongs to a particular major number should be done based on timestamp and not by text parsing the realname and finding out the number after the dot ?

9.Don't you think a file like libname.so.1(soname file) should NOT exist on disk.. Please check the attached picture. It is self explanatory as to how ldconfig creates a file named libname.so.1 (to help in it's processing ?) even if I have only 2 so's libname.so and libname.so.1.0. The fact that libname.so.1->libname.so.1.0 tells me what the purpose of the file is, and this will keep on getting updated as and when a new (minor number) version of the library is added. But surely, ldconfig doesn't need to show this file on disk, does it?

Please advise.
Thanks.

四月二日 当前只有等待等待

使用valgrind测试内存泄漏无法解决gsoap的问题。现在又遇到服务器端证书的问题，这个需要对于加密有更多的认识。制作LFS成了每天唯一能够作 的事情，nobrainer，而且可长可短。

四月十日 当前只有等待等待

昨天在折腾hnas，它的每一个server都有一个和自己kernel通讯的机制，一个叫做ssc的命令行工具。
如何修改svn的comment：  http://stackoverflow.com/questions/304383/how-do-i-edit-a-log-message-that-i-already-committed-in-subversion

$svn propedit -r N --revprop svn:log URL
$svn propset -r N --revprop svn:log "new log message" URL

之前发现gsoap对于zlib有依赖是因为它有实现一个http的压缩协议，这个是可选的：如果你没有configure  –DWITH_GZIP就不需要使用zlib了。
对于libssh2也同样是有对zlib的依赖：配置的时候有选项--without-libz
学习自动化的linux from scratch发现你要是使用不 同的用户，你必须登录才能执行，同时发现我的编译的内核的版本号结尾有个"+"脚本不能解读，只好重编内核。

四月十四日 当前只有等待等待

五月十八日 当前只有等待等待

libPocoDataSQLite.a

libPocoData.a

libPocoCrypto.a

libPocoNetSSL.a

libPocoNet.a

libPocoUtil.a

libPocoXML.a

libPocoFoundation.a

pthread

dl

Fame

Fame makes a man take things over
Fame lets him lose, hard to swallow
Fame puts you there where things are hollow
Fame

Fame, it's not your brain, it's just the flame
That burns your change to keep you insane
Fame

Fame, what you like is in the limo
Fame, what you get is no tomorrow
Fame, what you need you have to borrow
Fame

Fame, "Nein! It's mine!" is just his line
To bind your time, it drives you to crime
Fame

Could it be the best, could it be?
Really be, really babe?
Could it be my babe, could it, babe?
Could it, babe? Could it, babe?

Is it any wonder, I reject you first?
Fame, fame, fame
Is it any wonder you are too cool to fool?
Fame

Fame, bully for you, chilly for me
Got to get a rain check on pain

Fame

Fame, fame, fame, fame, fame
Fame, fame, fame, fame, fame
Fame, fame, fame, fame, fame
Fame, fame, fame, fame, fame
Fame, fame, fame

Fame, what's your name?

Feeling so gay
Feeling gay

五月二十八日 当前只有等待等待

try
{
     poco_throw_on_signal;
     ...
}
catch (Poco::SignalException&)
{
    ...
}

release编译下的全局变量通常在gdb里打印不一定有正确的数值。

最终这个signal转exception的权宜之计是不能根本解决问题的，因为我们能够捕捉到segmental violation的signal本身就说明代码错的非常厉害，catch这个转变的exception仅仅保住了本来crash的线程，防止了 mutex不释放造成的死锁，但是源头是什么？最后找到的原因是一个全局变量在被每个线程都创建与释放过程未保护导致了race condition，在某个线程获得了全局变量的指针后被其他线程释放从而内存成为自由区被别人任意写入导致的混乱，这个问题上个月已经遇到过类似的一 次，不过当时是因为interface指针没有引用计数，我必须要等待所有使用线程都结束以后才能释放。两者都是多线程环境下内存corruption只 不过后者并不是真的有race condition，前者才是而已。

现在开始使用ubuntu 14.04主要是主流的软件都在支持，编译开源容易。wesnoth的ai的训练场值得学习。命令是./wesnoth-debug -t ai_arena_small -dtry

五月三十一日 当前只有等待等待

六月三十日 当前只有等待等待

另一个小小的问题是关于destructor的，我们的基类是一个抽象类只定义了方法，忘记设定destructor为virtual，只是在它的 子类设定destructor为virtual，这样结果derived class不能自动调用它的destructor，所以这个virtual一定要在最早的祖先类来声明。现在debug deadlock确实还是有些心得，deadlock比race condition容易debug，只要debug编译，info thread，然后thread #到每个thread，取bt看看是否卡在我定义的mutex处，up/down到相应的frame然后print mutex可以看到它的owner的thread id，就八九不离十了。

七月二日 当前只有等待等待

遇到了一个Multiple inheritance的问题，而且还是所谓的diamond的问题。

class Base{public: void init_storage()=0; void base_init(){init_storage();}};

class FileBase:public Base{public: void init_storage(){cout<<"file init"<<endl;}};

class BlockBase:public Base{public: void init_storage(){cout<<"block init"<<endl;}};

class Hybrid:public FileBase, BlockBase{public: void exec(){base_init();}};   //////=========>>Here is ambiguious place, You don't know which init_storage it should call.

不过我们需要的是hybrid，就是说我需要两个继承类的init_storage，于是FileBase::init_storage();BlockBase::init_storage();这样子就可以了。

我重新改写了makefile的结构，依据这样一个架构：

0. target 1.srcs 2.objs 3. paths 4.cc_flags 5. ld_flags 6. obj_rules 7. target_rules 8. make_phony_target_rules

其中obj_rules可以非常的通用化：

%.o: ${SRC_PATH}/%.cpp

    CC_CMD -c ${CC_FLAGS} %< -o %@

七月九日 当前只有等待等待

在链接动态库时候，担心提供者不给symlink，比如libssl.so.1.0.0却不给libssl.so指向，于是我把通常的-L$ {SSL_LIB_PATH} -lssl改写成了-l:${SSL_LIB_PATH}/libssl.so.1.0.0这个做法在后来的ldd发现居然有个库是使用绝对路径，而不是 其他那样的库的名字，仿佛使用了类似r-path一样，迷惑了一下才发现那个绝对路径的是间接的库，比如我们的应用依赖关系如下webserver== >libHiStor.so==>libthird.so那么链接之后libthird.so就是全路经，而libHiStor.so还是正 常的libHiStor.so.SONAME

以上似乎是不对的，结论是永远永远不要使用动态库的绝对路径来链接。因为动态库链接另一个动态库如果使用绝对路径如同r-path一样是非常要命的。

另一个反复忘记的就是不论使用linux gcc还是cross gcc都是一样的，如果你要编译-shared都要-fPIC每一个obj文件，而不是仅仅.so的时候。

七月十日 当前只有等待等待

七月二十一日 当前只有等待等待

class Singlton

{

private:

Singlton(){cout << " a very long procedure" << endl;}

static Singlton* m_pSinglton;

public:

static Singlton* createSinglton();

};

Singlton* Singlton::m_pSinglton = NULL;

Singlton* Singlton::createSinglton()

{

    if (m_pSinglton == NULL)

    {

        LOCK myLock(g_mutex);

        if (m_pSinglton == NULL)

        {

            
Singlton* pTmp = NULL;

            if (Factory::create(&pTmp))

            {

                m_pSinglton = pTmp;

            }

        }

    }

}

关于gsoap的内存泄漏问题，在资讯其技术支持后意识到我把proxy和普通c style的函数混用了，而且其原则是init一定要在soap_new之类之后调用。而set_local_namespace这个东西在proxy里 已经有了不需要你自己去做了。使用valgrind可以很轻易的发现这些错误。

七月二十二日 当前只有等待等待

七月二十九日 当前只有等待等待

这里还有一个小虾米的搞笑三轮车，坏姐姐。文er的中气非常足，梦回当年古战场。

简单的看了一下poco的httpRequest类，实际是很简单的，因为uri指的就是/开始的部分，host:port不用说，不过输出的时候 有可能加[]在host上，如果其中包含:的话，不知道这个情况是什么意思。至于我一直想要找的serialization的方法也找到了，他的祖先类 httpmessage/httpheader类都有实现，read/write，所以这个是很直白的de/serialization。当然其中的 fields是用multi-map实现的，要小心重名，是否大小写区别呢？这个要证实。

八月十四日 当前只有等待等待

关于eclipse的老问题，就是使用gcc builtin 的设置。You could also try use "CDT GCC Built-in Compiler Settings". Go to the project properties > C/C++ General > Preprocessor Include Path > Providers tab then check "CDT GCC Built-in Compiler Settings" if it is not.

八月二十九日 当前只有等待等待

这里是关于dynamic调用的格式，这里就比较好理解了，无非就是一个_DYNAMIC的list里面是一系列的d_tag和地址的对子，对于dynamic object的执行有了一个框架的定义。所以，重复一下，dynamic library必须是有segment的而且要在program_header有一个PT_DYNAMIC的element,在segment里有这个_DYNAMIC的list。（我把人家的话抄了一下改了一下顺序说了一遍，这个是典型的plagerism）

Position                                                                            
Value

e_ident[EI_CLASS]                                                     
ELFCLASS64

e_ident[EI_DATA]                                                        
ELFDATA2LSB

我抄下这个警句：Processor identification resides in the ELF headers e_machine member and must have the value EM_X86_64（从注释中发现它的值是62）（找时间看一下file的命令的实现就知道了。）
从白虎阶堂的军用地图看到了一大堆的文献，比较粗浅的是fhs(fileystem hierarchy standard)
什么时候弄一个cronjob来定期更新呢？

九月二日 当前只有等待等待

使用readelf --debug-dump=decodedline ./myElf看到了debug的信息，大开眼界，感觉真是孤陋寡闻。

九月十八日 当前只有等待等待

<builtin-type> ::= v    # void

         ::= w    # wchar_t

         ::= b    # bool

         ::= c    # char

         ::= a    # signed char

         ::= h    # unsigned char

         ::= s    # short

         ::= t    # unsigned short

         ::= i    # int

         ::= j    # unsigned int

         ::= l    # long

         ::= m    # unsigned long

         ::= x    # long long, __int64

         ::= y    # unsigned long long, __int64

         ::= n    # __int128

         ::= o    # unsigned __int128

         ::= f    # float

         ::= d    # double

         ::= e    # long double, __float80

         ::= g    # __float128

         ::= z    # ellipsis

                
::= Dd # IEEE 754r decimal floating point (64 bits)

                
::= De # IEEE 754r decimal floating point (128 bits)

                
::= Df # IEEE 754r decimal floating point (32 bits)

                
::= Dh # IEEE 754r half-precision floating point (16 bits)

                 ::= Di # char32_t

                 ::= Ds # char16_t

                 ::= Da # auto

                 ::= Dc # decltype(auto)

                
::= Dn # std::nullptr_t (i.e., decltype(nullptr))

         ::= u <source-name>    # vendor extended type