LovesTha
20th March 2009, 07:58
Lets see if I can give enough information for someone to point out the glaring issue I have.
Firstly a list of the weird aspects of how I'm trying to work currently:
Qt package I'm using: qt-embedded-linux-opensource-src-4.5.0 (trying to use Qt on a small embedded arm linux platform,
Qt compilation setup: Ubuntu x86-64, cross compilation tool chain supplied by Technologic Systems with the system I am targeting. The tool chain binaries path is added to the start of the $PATH before I try to ./configure and compile. The programs in that folder have all been renamed "arm-linux-*" so that the Qt scripts see them.
Qt linking setup: Windows using Eclipse as supplied by Technologic Systems using the same cross compilation tool chain, this setup has worked and linked other non trivial but smaller libraries.
./configure options:
./configure -embedded arm -xplatform qws/linux-arm-g++ -little-endian -L /data/TS-7800/devel-tools/crosstool-lin/arm-none-linux-gnueabi/sys-root/usr/lib/ -static -stl -silent -prefix /data/TS-7800/LibBuild/Output
nice and boring call to make: make -j 12
the ./configure and make have a few warnings but nothing I've noticed that is scary and no errors.
So now I move the includes folder from the -prefix folder to where I'm including things from in Windows, and the lib folder to where I've got Eclipse looking for library files. This appears to make sense to me and should to my simple mind be what I need.
All of my code compiles, and the linker can find the library files and the link command looks like:
arm-none-linux-gnueabi-g++.exe -LC:\Eclipse\devel-tools\crosstool-win\arm-none-linux-gnueabi\GPSat\Link -LC:\Eclipse\workspace\Library\Debug -LC:\Eclipse\devel-tools\crosstool-win\arm-none-linux-gnueabi\GPSat -LC:\Eclipse\devel-tools\crosstool-win\arm-none-linux-gnueabi\GPSatLib\inc -static -oGPSat src\UDPTest.o -lQt3Support -lQtCore -lQtGui -lQtNetwork -lQtScript -lQtScriptTools -lQtSql -lQtSvg -lQtTest -lQtWebKit -lQtXml -lGPSat -lsolid
With the first segment of errors looking like:
C:\Eclipse\workspace\Library\Debug\libGPSat.a(GUDP Channel.o): In function `GUDPChannel':..\src/GUDPChannel.cpp:4: undefined reference to `QObject::QObject(QObject*)'
:..\src/GUDPChannel.cpp:4: undefined reference to `QUdpSocket::QUdpSocket(QObject*)'
:..\src/GUDPChannel.cpp:6: undefined reference to `qFlagLocation(char const*)'
:..\src/GUDPChannel.cpp:6: undefined reference to `qFlagLocation(char const*)'
:..\src/GUDPChannel.cpp:6: undefined reference to `QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType)'
:..\src/GUDPChannel.cpp:6: undefined reference to `QUdpSocket::~QUdpSocket()'
:..\src/GUDPChannel.cpp:6: undefined reference to `QObject::~QObject()'
:..\src/GUDPChannel.cpp:8: undefined reference to `vtable for GUDPChannel'
:..\src/GUDPChannel.cpp:4: undefined reference to `QObject::QObject(QObject*)'
:..\src/GUDPChannel.cpp:4: undefined reference to `QUdpSocket::QUdpSocket(QObject*)'
using the objdump tool I can see that the .a files used for the linking contain lots of stuff (there size also shows this ~195meg for the lib folder) and that QObject is mentioned in them. There appears to be way to much stuff for me to determine what exsactly is in there, but I feel that the files contain definitions for the above errors. So I'm a bit perplexed.
I'm not compiling Qt on windows because the environment can't manage to do the 'compiling qmake' step of the ./configure script.
I'm using static linking because the Linux environment were using is configured for old eabi format but we want the better FPU performance of the gnueabi option. (yes I'm aware of the legal implications of LGPL + static linking) This calling convention issue may be what my problem is.
Can anyone give me some help on this? Despite the large amount of data I've put here I'm sure I haven't mentioned something of importance and will strive to make it as easy as possible for people to help me.
Firstly a list of the weird aspects of how I'm trying to work currently:
Qt package I'm using: qt-embedded-linux-opensource-src-4.5.0 (trying to use Qt on a small embedded arm linux platform,
Qt compilation setup: Ubuntu x86-64, cross compilation tool chain supplied by Technologic Systems with the system I am targeting. The tool chain binaries path is added to the start of the $PATH before I try to ./configure and compile. The programs in that folder have all been renamed "arm-linux-*" so that the Qt scripts see them.
Qt linking setup: Windows using Eclipse as supplied by Technologic Systems using the same cross compilation tool chain, this setup has worked and linked other non trivial but smaller libraries.
./configure options:
./configure -embedded arm -xplatform qws/linux-arm-g++ -little-endian -L /data/TS-7800/devel-tools/crosstool-lin/arm-none-linux-gnueabi/sys-root/usr/lib/ -static -stl -silent -prefix /data/TS-7800/LibBuild/Output
nice and boring call to make: make -j 12
the ./configure and make have a few warnings but nothing I've noticed that is scary and no errors.
So now I move the includes folder from the -prefix folder to where I'm including things from in Windows, and the lib folder to where I've got Eclipse looking for library files. This appears to make sense to me and should to my simple mind be what I need.
All of my code compiles, and the linker can find the library files and the link command looks like:
arm-none-linux-gnueabi-g++.exe -LC:\Eclipse\devel-tools\crosstool-win\arm-none-linux-gnueabi\GPSat\Link -LC:\Eclipse\workspace\Library\Debug -LC:\Eclipse\devel-tools\crosstool-win\arm-none-linux-gnueabi\GPSat -LC:\Eclipse\devel-tools\crosstool-win\arm-none-linux-gnueabi\GPSatLib\inc -static -oGPSat src\UDPTest.o -lQt3Support -lQtCore -lQtGui -lQtNetwork -lQtScript -lQtScriptTools -lQtSql -lQtSvg -lQtTest -lQtWebKit -lQtXml -lGPSat -lsolid
With the first segment of errors looking like:
C:\Eclipse\workspace\Library\Debug\libGPSat.a(GUDP Channel.o): In function `GUDPChannel':..\src/GUDPChannel.cpp:4: undefined reference to `QObject::QObject(QObject*)'
:..\src/GUDPChannel.cpp:4: undefined reference to `QUdpSocket::QUdpSocket(QObject*)'
:..\src/GUDPChannel.cpp:6: undefined reference to `qFlagLocation(char const*)'
:..\src/GUDPChannel.cpp:6: undefined reference to `qFlagLocation(char const*)'
:..\src/GUDPChannel.cpp:6: undefined reference to `QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType)'
:..\src/GUDPChannel.cpp:6: undefined reference to `QUdpSocket::~QUdpSocket()'
:..\src/GUDPChannel.cpp:6: undefined reference to `QObject::~QObject()'
:..\src/GUDPChannel.cpp:8: undefined reference to `vtable for GUDPChannel'
:..\src/GUDPChannel.cpp:4: undefined reference to `QObject::QObject(QObject*)'
:..\src/GUDPChannel.cpp:4: undefined reference to `QUdpSocket::QUdpSocket(QObject*)'
using the objdump tool I can see that the .a files used for the linking contain lots of stuff (there size also shows this ~195meg for the lib folder) and that QObject is mentioned in them. There appears to be way to much stuff for me to determine what exsactly is in there, but I feel that the files contain definitions for the above errors. So I'm a bit perplexed.
I'm not compiling Qt on windows because the environment can't manage to do the 'compiling qmake' step of the ./configure script.
I'm using static linking because the Linux environment were using is configured for old eabi format but we want the better FPU performance of the gnueabi option. (yes I'm aware of the legal implications of LGPL + static linking) This calling convention issue may be what my problem is.
Can anyone give me some help on this? Despite the large amount of data I've put here I'm sure I haven't mentioned something of importance and will strive to make it as easy as possible for people to help me.