（C++）glibmm不會在Ubuntu鏈接/解夢

Question

我有無比的在Ubuntu簡單的程序/解夢問題：

#include <glibmm/ustring.h> 

int main() 
{ 
    Glib::ustring s = "Test string"; 
} 

使用的Makefile

PACKAGES=glibmm-2.4 glib-2.0 gtkmm-3.0 gtk+-3.0 
CC=g++ 
CFLAGS=`pkg-config --cflags $(PACKAGES)` --std=c++0x 
LD=g++ 
LDFLAGS=`pkg-config --libs $(PACKAGES)` 

build: ./main 

run: build 
    ./main 

clean: 
    rm ./main.o 

rebuild: clean build 

./main: ./main.o 
    $(LD) $(LDFLAGS) ./main.o -o ./main 

./main.o: ./main.cc 
    $(CC) $(CFLAGS) ./main.cc -c -o ./main.o 

在化妝以下錯誤出現：

./main.o: In function `main': 
main.cc:(.text+0x15): undefined reference to `Glib::ustring::ustring(char const*)' 
main.cc:(.text+0x21): undefined reference to `Glib::ustring::~ustring()' 
collect2: ld returned 1 exit status 
make: *** [main] Error 1 

在Ubuntu/Maverick上，完全相同的代碼鏈接以及完全相同的文件... 如果使用ld在main.o它也成功鏈接，但（如預期）_start丟失...

有什麼建議嗎？

Answer 1

嘗試改變相關線路這樣：

LDFLAGS=`pkg-config --libs-only-L --libs-only-other $(PACKAGES)` 
LIBS=`pkg-config --libs-only-l $(PACKAGES)` 

# ... 

./main: ./main.o 
    $(LD) $(LDFLAGS) ./main.o -o ./main $(LIBS) 

的原因是，該連接器可以搜索庫中，他們在命令行上給定的順序，所以他們應該始終放在最後是安全的。