Help - Search - Members - Calendar
Full Version: Compile Error On Float Point Problem
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > pdaXrom
wellswang
I want to re-compile Justreader for hacking some code,
but when 'make' to this process:

CODE
g++  -o dist/usr/lib/qt/bin/justreader TextReader.o main.o FileDialog.o SettingsDlg.o ColorComboBox.o SelectKeyButton.o toUnicode.o Bookmarks.o Stream.o StreamHTML.o StreamTXT.o StreamPlucker.o StreamPalmDoc.o StreamPalmTXT.o StreamPalmHTML.o StreamPalmMP.o Frame.o IntDict.o Control.o dictionary.o file.o shc.o shcm.o utf8.o Unzip.o unzip.o makedoc9.o Palm2QImage.o config.o moc_TextReader.o moc_FileDialog.o moc_SettingsDlg.o moc_ColorComboBox.o moc_SelectKeyButton.o moc_Bookmarks.o moc_Control.o   -Wl,-rpath,/mnt/zgcc/qt3//lib -L/mnt/zgcc/qt3//lib -L/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib -lqt-mt -lXext -lX11 -lm -Wl,-rpath-link,/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib


i got many error messages like below one:

CODE
/opt/native/arm/3.4.6-xscale-softvfp/lib/gcc/armv5tel-cacko-linux/3.4.6/../../../../armv5tel-cacko-linux/bin/ld: ERROR: TextReader.o uses FPA instructions, whereas dist/usr/lib/qt/bin/justreader does not


but i've add -msoft-float parameter to gcc ,
it doesnot work ...

my gcc parameter is :
CODE
CFLAGS   = -pipe -Wall -W -O2 -fomit-frame-pointer -mcpu=iwmmxt -mtune=iwmmxt  -D__FOR_QT__ -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT -msoft-float
CXXFLAGS = -pipe -Wall -W -O2 -fomit-frame-pointer -mcpu=iwmmxt -mtune=iwmmxt -fno-exceptions -fno-rtti  -D__FOR_QT__ -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT -msoft-float


I am using gcc 3.4.6 from pdaXrom_1.1.0beta3 official feed

Anybody can help me ?
Thanks.

--wells.
Meanie
QUOTE(wellswang @ Mar 6 2007, 03:48 PM)
I want to re-compile Justreader for hacking some code,
but when 'make' to this process:

CODE
g++  -o dist/usr/lib/qt/bin/justreader TextReader.o main.o FileDialog.o SettingsDlg.o ColorComboBox.o SelectKeyButton.o toUnicode.o Bookmarks.o Stream.o StreamHTML.o StreamTXT.o StreamPlucker.o StreamPalmDoc.o StreamPalmTXT.o StreamPalmHTML.o StreamPalmMP.o Frame.o IntDict.o Control.o dictionary.o file.o shc.o shcm.o utf8.o Unzip.o unzip.o makedoc9.o Palm2QImage.o config.o moc_TextReader.o moc_FileDialog.o moc_SettingsDlg.o moc_ColorComboBox.o moc_SelectKeyButton.o moc_Bookmarks.o moc_Control.o   -Wl,-rpath,/mnt/zgcc/qt3//lib -L/mnt/zgcc/qt3//lib -L/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib -lqt-mt -lXext -lX11 -lm -Wl,-rpath-link,/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib


i got many error messages like below one:

CODE
/opt/native/arm/3.4.6-xscale-softvfp/lib/gcc/armv5tel-cacko-linux/3.4.6/../../../../armv5tel-cacko-linux/bin/ld: ERROR: TextReader.o uses FPA instructions, whereas dist/usr/lib/qt/bin/justreader does not


but i've add -msoft-float parameter to gcc ,
it doesnot work ...

my gcc parameter is :
CODE
CFLAGS   = -pipe -Wall -W -O2 -fomit-frame-pointer -mcpu=iwmmxt -mtune=iwmmxt  -D__FOR_QT__ -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT -msoft-float
CXXFLAGS = -pipe -Wall -W -O2 -fomit-frame-pointer -mcpu=iwmmxt -mtune=iwmmxt -fno-exceptions -fno-rtti  -D__FOR_QT__ -DQT_NO_DEBUG -DQT_SHARED -DQT_THREAD_SUPPORT -msoft-float


I am using gcc 3.4.6 from pdaXrom_1.1.0beta3  official feed

Anybody can help me ?
Thanks.

--wells.
*


you can't add -msoft-float as it conflicts with the pdaXrom gcc toolchain which has been compiled with soft-vfp and you cannot mix the two.
also, it looks strange that you are linking in files from /mnt/zgcc/qt3/lib while rpathing /opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib

I recommend you to use my customized zgcc-3.4.6.squashfs instead. it can build justreader just fine with just qmake justreader.pro followed by make
only difference is that my specs file uses xscale instead iwmmxt for the mcpu and mtune flags, but you can easily change that wink.gif
wellswang
thanks, meanie~

I will try it again.

-wells.
radiochickenwax
QUOTE(Meanie @ Mar 6 2007, 06:05 AM)
you can't add -msoft-float as it conflicts with the pdaXrom gcc toolchain which has been compiled with soft-vfp and you cannot mix the two.
*



Well, I've asked this before and gotten no response, but I can't help asking again:

How can one replace the gcc-toolchain? I've recompiled gcc with this option enabled, (to try to use fortran natively) but it's really unstable. It compiles some stuff, but not others, and most problems come at the linking stage. (similar to the original post). I guess this isn't really the forum for this kind of question, but I'd really like to hear what anyone has to say in this regard.

Would replacing libgcc with the altered floating point calculators necessitate a whole new rom? I realize I'm out of my depth here, but I don't intend to stay there. I really want to get fortran working natively.
Ikkakujyu
QUOTE(radiochickenwax @ Mar 6 2007, 04:43 PM)
Would replacing libgcc with the altered floating point calculators necessitate a whole new rom?  I realize I'm out of my depth here, but I don't intend to stay there.  I really  want to get fortran working natively.
*


As has been stated, you can't mix floating point implementations, so you'd have to rebuild the entire system.

Of course, EABI allows you to mix-and-match... just, you -still- need to recompile the whole system to be EABI aware :/
radiochickenwax
QUOTE(Ikkakujyu @ Mar 7 2007, 08:30 AM)
QUOTE(radiochickenwax @ Mar 6 2007, 04:43 PM)
Would replacing libgcc with the altered floating point calculators necessitate a whole new rom?  I realize I'm out of my depth here, but I don't intend to stay there.  I really  want to get fortran working natively.
*


As has been stated, you can't mix floating point implementations, so you'd have to rebuild the entire system.

Of course, EABI allows you to mix-and-match... just, you -still- need to recompile the whole system to be EABI aware :/
*



(Realizing my earlier post was a little unclear).

Yes, altered floating-point implementations would need a new "libc" and all programs would need to be aware of this, but what about the plain old "libgcc" which is all I'm trying to replace?

I'm not really interested in changing the floating-point implementation (yet). I just want a new gcc-toolchain. I find it difficult to believe that rebuilding the same toolchain that the existing ROM uses with support for additional languages should need a whole new ROM.

I just want a system that runs fortran natively. The compilation of g77 is reasonably straight-forward, but the resulting library (libgcc) is not. (at least to me).

It took me a long time of playing around on an already slow machine just to get the gcc toolchain's source-code to build. Maybe I didn't give it enough of a chance.
Ikkakujyu
QUOTE(radiochickenwax @ Mar 12 2007, 05:07 PM)
It took me a long time of playing around on an already slow machine just to get the gcc  toolchain's source-code to build.  Maybe I didn't give it enough of a chance.
*


The Linux From Scratch project has notes on building an entire toolchain, you should read up on it. It shouldn't be too different to adapt to the 3.6 GCC. If it doesn't work, try to find the archived older versions.

It's a long process to get it right - you have to build GCC, use that to build Glibc, then rebuild GCC to link against the newly-created Glibc. Since pdaXrom already has Glibc built, you can probably skip most of that.

Read up on the whole thing, though - it's pretty enlightening.
Meanie
QUOTE(radiochickenwax @ Mar 13 2007, 11:07 AM)
QUOTE(Ikkakujyu @ Mar 7 2007, 08:30 AM)
QUOTE(radiochickenwax @ Mar 6 2007, 04:43 PM)
Would replacing libgcc with the altered floating point calculators necessitate a whole new rom?  I realize I'm out of my depth here, but I don't intend to stay there.  I really  want to get fortran working natively.
*


As has been stated, you can't mix floating point implementations, so you'd have to rebuild the entire system.

Of course, EABI allows you to mix-and-match... just, you -still- need to recompile the whole system to be EABI aware :/
*



(Realizing my earlier post was a little unclear).

Yes, altered floating-point implementations would need a new "libc" and all programs would need to be aware of this, but what about the plain old "libgcc" which is all I'm trying to replace?

I'm not really interested in changing the floating-point implementation (yet). I just want a new gcc-toolchain. I find it difficult to believe that rebuilding the same toolchain that the existing ROM uses with support for additional languages should need a whole new ROM.

I just want a system that runs fortran natively. The compilation of g77 is reasonably straight-forward, but the resulting library (libgcc) is not. (at least to me).

It took me a long time of playing around on an already slow machine just to get the gcc toolchain's source-code to build. Maybe I didn't give it enough of a chance.
*



did you use the pdaXrom toolchain (which is softvfp enabled) to compile fortran or did you use your own DIY toolchain which uses soft-float/fpa to compile fortran? the latter would build a completely incompatible libgcc
also, you need to build fortran from the same gnu compiler version as the pdaXrom toolchain, ie 3.4.6 sources of fortran, otherwise you will be building a different version of libgcc.
radiochickenwax
QUOTE(Ikkakujyu @ Mar 13 2007, 02:20 AM)
The Linux From Scratch project has notes on building an entire toolchain, you should read up on it. It shouldn't be too different to adapt to the 3.6 GCC. If it doesn't work, try to find the archived older versions.
*



Yes, I've been reading up on that. Great project, thanks.


QUOTE(Ikkakujyu @ Mar 13 2007, 02:20 AM)
It's a long process to get it right - you have to build GCC, use that to build Glibc, then rebuild GCC to link against the newly-created Glibc. Since pdaXrom already has Glibc built, you can probably skip most of that.
*


It certainly is a long process. Like you said, and for the same reasons, I'm not trying to rebuild glibc (yet).



QUOTE(Meanie @ Mar 13 2007, 08:19 AM)
did you use the pdaXrom toolchain (which is softvfp enabled) to compile fortran or did you use your own DIY toolchain which uses soft-float/fpa to compile fortran? the latter would build a completely incompatible libgcc
also, you need to build fortran from the same gnu compiler version as the pdaXrom toolchain, ie 3.4.6 sources of fortran, otherwise you will be building a different version of libgcc.
*


I've actually tried all of the above, as well as cross-tool. I was using gcc3.4.5 to compile gcc3.4.5. The only partial successes I believe I've gotten thus far were from the pdaXrom x86 softvfp cross-compiler in one try and the native pdaXrom toolchain in another. I'm not sure what's going wrong with the resulting toolchain anymore, since I haven't had a chance to try it again for a few weeks. The last I remember is that it wasn't linking compiled code into executable code somehow.

I'm sure to give this another try in the near future, even if it means starting completely from scratch as was suggested.

Thanks for the responses, I guess there's not much of a demand for fortran in pdaxrom, or if there is, it's fairly silent. I do very much appreciate the assistance.
Meanie
QUOTE(radiochickenwax @ Mar 16 2007, 09:38 AM)
QUOTE(Ikkakujyu @ Mar 13 2007, 02:20 AM)
The Linux From Scratch project has notes on building an entire toolchain, you should read up on it. It shouldn't be too different to adapt to the 3.6 GCC. If it doesn't work, try to find the archived older versions.
*



Yes, I've been reading up on that. Great project, thanks.


QUOTE(Ikkakujyu @ Mar 13 2007, 02:20 AM)
It's a long process to get it right - you have to build GCC, use that to build Glibc, then rebuild GCC to link against the newly-created Glibc. Since pdaXrom already has Glibc built, you can probably skip most of that.
*


It certainly is a long process. Like you said, and for the same reasons, I'm not trying to rebuild glibc (yet).



QUOTE(Meanie @ Mar 13 2007, 08:19 AM)
did you use the pdaXrom toolchain (which is softvfp enabled) to compile fortran or did you use your own DIY toolchain which uses soft-float/fpa to compile fortran? the latter would build a completely incompatible libgcc
also, you need to build fortran from the same gnu compiler version as the pdaXrom toolchain, ie 3.4.6 sources of fortran, otherwise you will be building a different version of libgcc.
*


I've actually tried all of the above, as well as cross-tool. I was using gcc3.4.5 to compile gcc3.4.5. The only partial successes I believe I've gotten thus far were from the pdaXrom x86 softvfp cross-compiler in one try and the native pdaXrom toolchain in another. I'm not sure what's going wrong with the resulting toolchain anymore, since I haven't had a chance to try it again for a few weeks. The last I remember is that it wasn't linking compiled code into executable code somehow.

I'm sure to give this another try in the near future, even if it means starting completely from scratch as was suggested.

Thanks for the responses, I guess there's not much of a demand for fortran in pdaxrom, or if there is, it's fairly silent. I do very much appreciate the assistance.
*



Note that building from scratch is not the option that you want because that would mean a complete new and incompatible gcc unless you can build a soft-vfp enabled gcc from scratch for which you need sashz' special patches...
radiochickenwax
QUOTE(Meanie @ Mar 16 2007, 12:16 AM)
Note that building from scratch is not the option that you want because that would mean a complete new and incompatible gcc unless you can build a soft-vfp enabled gcc from scratch for which you need sashz' special patches...
*



Yeah, that's a problem. The special patches are available on SVN? It's gonna take me awhile to get the hang of learning to apply them I think.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.