OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> can't link x86 binaries for testing in qvfb
ceratophyllum
post Jan 7 2020, 08:31 AM
Post #1





Group: Members
Posts: 8
Joined: 1-January 20
Member No.: 862,598



So I set up SuSE 8.2 in VirtualBox and installed the RPMs located here:
http://www.ossh.com/zaurus/mirrors/docs.za...tup_howto.shtml

No funny errors or warnings; they just installed.

I can build the example for arm and I was able to compile Frotz 2.50 (dumb version; ncurses is a mess).
I tested and the arm dfrotz binary works fine on my Zaurus.

However, I when I try to build the x86 example binary for testing in qvfb, I get a bunch of undefined symbols when gcc tries to link it.

Am I missing some RPMs?

qvfb works with the prebuilt binaries in /opt/Qtopia/bin and it would sure speed things up to be able to build things and test them without having to transfer them to the Zaurus.

Here is some of the output:

CODE
ld: warning: cannot find entry symbol _start; defaulting to 0000000008048270
main.o(.text+0x1e): In function `main':
: undefined reference to `QPEApplication::QPEApplication(int&, char**, QApplication::Type)'
main.o(.text+0x3f): In function `main':
: undefined reference to `QPEApplication::showMainWidget(QWidget*, bool)'
main.o(.text+0x47): In function `main':
: undefined reference to `QPEApplication::exec()'
main.o(.text+0x5a): In function `main':
: undefined reference to `QPEApplication::~QPEApplication()'
main.o(.gnu.linkonce.t._ZN7QGArrayaSERKS_+0x5): In function `QGArray::operator=(QGArray const&)':
: undefined reference to `QGArray::assign(QGArray const&)'
main.o(.gnu.linkonce.t._ZN7QGArray6detachEv+0xc): In function `QGArray::detach()':
: undefined reference to `QGArray::duplicate(QGArray const&)'
main.o(.gnu.linkonce.t._ZN11QStringDataD2Ev+0x35): In function `QStringData::~QStringData()':
: undefined reference to `operator delete[](void*)'
main.o(.gnu.linkonce.t._ZN11QStringDataD2Ev+0x28): In function `QStringData::~QStringData()':
: undefined reference to `operator delete[](void*)'
main.o(.gnu.linkonce.t._ZN11QStringDataD1Ev+0x35): In function `QStringData::~QStringData()':
: undefined reference to `operator delete[](void*)'
main.o(.gnu.linkonce.t._ZN11QStringDataD1Ev+0x28): In function `QStringData::~QStringData()':
: undefined reference to `operator delete[](void*)'
main.o(.gnu.linkonce.t._ZNK7QString8containsEcb+0x1f): In function `QString::contains(char, bool) const':
: undefined reference to `QString::contains(QChar, bool) const'
main.o(.gnu.linkonce.t._ZN7QString6insertEjc+0x1d): In function `QString::insert(unsigned, char)':
: undefined reference to `QString::insert(unsigned, QChar)'
main.o(.gnu.linkonce.t._ZNK7QString2atEj+0x13): In function `QString::at(unsigned) const':
: undefined reference to `QChar::null'
main.o(.gnu.linkonce.t._ZN7QString3refEj+0x18): In function `QString::ref(unsigned)':
: undefined reference to `QString::subat(unsigned)'
main.o(.gnu.linkonce.t._ZNK7QStringcvPKcEv+0x5): In function `QString::operator char const*() const':
: undefined reference to `QString::latin1() const'
main.o(.gnu.linkonce.t._ZN7QString7compareERKS_S1_+0x5): In function `QString::compare(QString const&, QString const&)':

Attached thumbnail(s)
Attached Image
 
Go to the top of the page
 
+Quote Post
Varti
post Jan 9 2020, 02:52 AM
Post #2





Group: Admin
Posts: 984
Joined: 30-April 08
From: Italy
Member No.: 21,713



Just a quick check: are you switching to the x86 environment variables with the dev-x86-qpe.sh script, and running again tmake to rebuild the Makefile before attempting to compile the binary?

It would be great if you could release any package you manage to compile, in case anyone would need them. I can setup on the OESF's server a public feed with all the stuff you'd like to share, just let me know.

Varti
Go to the top of the page
 
+Quote Post
ceratophyllum
post Jan 9 2020, 07:18 AM
Post #3





Group: Members
Posts: 8
Joined: 1-January 20
Member No.: 862,598



QUOTE(Varti @ Jan 9 2020, 05:52 AM) *
Just a quick check: are you switching to the x86 environment variables with the dev-x86-qpe.sh script, and running again tmake to rebuild the Makefile before attempting to compile the binary?

It would be great if you could release any package you manage to compile, in case anyone would need them. I can setup on the OESF's server a public feed with all the stuff you'd like to share, just let me know.

Varti

Yes, I read the directions and followed them. It looks like someone else--using a distro from around the same time--has had this problem:
https://www.oesf.org/forum/index.php?showtopic=2045

It is probably because the distro's x86 gcc 3.2 is too new. The arm-linux-gcc is 2.92.2. It is suggested in the post above that upgrading to qtopia-free 1.7 will fix things for gcc 3.x.
Unfortunately, qtopia-free-1.7.0-2rh9.i386.rpm is noplace. Everyone just has a broken link to ftp.trolltech.com.
Go to the top of the page
 
+Quote Post
ceratophyllum
post Jan 9 2020, 08:03 AM
Post #4





Group: Members
Posts: 8
Joined: 1-January 20
Member No.: 862,598



QUOTE(ceratophyllum @ Jan 9 2020, 10:18 AM) *
QUOTE(Varti @ Jan 9 2020, 05:52 AM) *
Just a quick check: are you switching to the x86 environment variables with the dev-x86-qpe.sh script, and running again tmake to rebuild the Makefile before attempting to compile the binary?

It would be great if you could release any package you manage to compile, in case anyone would need them. I can setup on the OESF's server a public feed with all the stuff you'd like to share, just let me know.

Varti

Yes, I read the directions and followed them. It looks like someone else--using a distro from around the same time--has had this problem:
https://www.oesf.org/forum/index.php?showtopic=2045

It is probably because the distro's x86 gcc 3.2 is too new. The arm-linux-gcc is 2.92.2. It is suggested in the post above that upgrading to qtopia-free 1.7 will fix things for gcc 3.x.
Unfortunately, qtopia-free-1.7.0-2rh9.i386.rpm is noplace. Everyone just has a broken link to ftp.trolltech.com.


Ok, it definitely is the compiler. The problem is in dev-x86-qpe.sh. It is assuming you have gcc 2.9XXX installed in /usr/local/x86and putting this path at the beginning of $PATH. Since I don't have that, it just picks up the distro's gcc 3.3 farther down in the PATH list.

I guess /usr/local/x86 was where RedHat put it's "compat" version of gcc2.

Fortunately, I found binaries of gcc 2.96.3 in here https://feed-zaurus.dahwa.fr/zaurusfr/sdk/Embedix.tgz .To get things working, I just extracted the archive and put ~/Embedix/native/bin at the beginning of the PATH= line in dev-x86-qpe.sh.
Attached thumbnail(s)
Attached Image
 
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 3rd April 2020 - 03:44 PM