[linrad] Re: Fwd: Linrad and 64 bits...
Hi, All, The compile of Linrad dies close to the finish line for reasons related to our beloved svgalib and libX11 utilities. Here is the story so far: Adding the -m32 flag to Makefile,in in 4 places [after the = sign on the two lines at the beginning of the file starting with CFL and CFW, and after the 'gcc' in two lines beginning with 'gcc' later in the file] eliminates the date type size error messages, and Linrad compiles OK down to the output: membeg.ol lmain.ol linvar.ol ui.ol lsetad.ol fft1.ol buf.ol \ mouse.ol wide_graph.ol getiq.ol fft0.ol adtest.ol hires_graph.ol \ fftasm.ol baseb_graph.ol mix2.ol afc_graph.ol hwaredriver.ol \ sellim.ol palette.ol gifsave.ol timing.ol help.ol calibrate.ol \ calsub.ol calsub2.ol llsqvar.ol llsq.ol caliq.ol timf2.ol \ powtim.ol selvar.ol fft2var.ol sigvar.ol screenvar.ol uivar.ol \ fft1var.ol fft3var.ol calvar.ol blnkvar.ol fft1_re.ol lxsys.ol \ fft1_complex.ol powtvar.ol simdasm.ol blank1.ol fft2.ol \ pol_graph.ol split.ol modesub.ol spur.ol cohsub.ol coherent.ol \ eme.ol spursub.ol freq_control.ol fft2mmxb.ol fft2mmxa.ol \ rxin.ol wcw.ol mix1.ol afcsub.ol morse.ol menu.ol fonts.ol \ tune.ol txtest.ol lnetwork.ol fft2mmxc.ol hware.ol coh_osc.ol \ cwspeed.ol sdrvar.ol sdr14.ol keyboard_var.ol thrvar.ol \ lsys.ol vlab.ol screen.ol netvar.ol settx.ol cwdetect.ol \ txvar.ol screensub.ol fft3.ol memend.ol The compilation then fails and gives the error messages: /usr/bin/ld: skipping incompatible /usr/local/lib/libvgagl.so when searching for -lvgagl /usr/bin/ld: cannot find -lvgagl collect2: ld returned 1 exit status which I assume means that next we need to get some 32 bit compatible svgalib stuff working. As would be expected, make xlinrad similarly fails for presumably similar reasons with: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libX11.a when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libX11.a when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib/libX11.a when searching for -lX11 /usr/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status make: *** [xlinrad] Error 1. and so 32 bit-compatible versions of this will need to be installed. To get linrad.exe to compile, mingw32svc-gcc needs to be installed and placed properly for starters, and who knows what will crop up once that is done. Sorry I don't have the complete answer, but this is a start. Remember, I am not a computer guy and never will be... 73, W3SZ Roger Rehr http://www.nitehawk.com/w3sz Quoting Roger Rehr <[EMAIL PROTECTED]>: Hi, I installed the following file via apt-get: libc6-dev-i386 and, having done this, gcc -m32 test.c works and gives the desired output: char 1 short int 2 int 4 long int 4 long unsigned int 4 Thus compiling Linrad in this fashion [gcc -m32] should work with the 64 bit gcc compiler. ia32-libs was already installed. If it is not on your system already you may need it. I just added this to the previous post so all the info can be found easily in the future. 73, W3SZ Roger Rehr http://www.nitehawk.com/w3sz Quoting Roger Rehr <[EMAIL PROTECTED]>: HI, Ernst, The problem is one of data type size differences between the 64 and 32 bit compilers, I think. See below for details. I have checked and found my email regarding 64 bit Ubuntu and Linrad from last September, and my error messages on compiling Linrad were identical to yours [slight difference in line numbers due to different versions of Linrad]. My notes at the time included: -start quote from September 2006: First errors [in a long list] noted: calibrate.c: In function ?final_filtercorr_init?: calibrate.c:401: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int? calibrate.c:401: warning: format ?%d? expects type ?int?, but argument 4 has type ?long unsigned int? The statement in question [401] is: sprintf(s,"File size reduced from %d to %d bytes", 5*fft1_size*sizeof(float)+20*sizeof(int), 5*siz*sizeof(float)+20*sizeof(int)); I imagine this will be occurring at other spots as well. I tried a quick [and potentially dangerous] fix by 'casting' the integer as follows: sprintf(s,"File size reduced from %d to %d bytes", (int)(5*fft1_size*sizeof(float)+20*sizeof(int)), (int)(5*siz*sizeof(float)+20*sizeof(int))); This of course just got me the warning: cc1: warnings being treated as errors buf.c: In function ?init_blanker?: buf.c:1364: warning: cast from pointer to integer of different size buf.c:1364: warning: cast to pointer from integer of different size because the compiler didn't like tha cast that was do
[linrad] Re: Fwd: Linrad and 64 bits...gcc -m32 works
Hi, I installed the following file via apt-get: libc6-dev-i386 and, having done this, gcc -m32 test.c works and gives the desired output: char 1 short int 2 int 4 long int 4 long unsigned int 4 Thus compiling Linrad in this fashion [gcc -m32] should work with the 64 bit gcc compiler. ia32-libs was already installed. If it is not on your system already you may need it. I just added this to the previous post so all the info can be found easily in the future. 73, W3SZ Roger Rehr http://www.nitehawk.com/w3sz Quoting Roger Rehr <[EMAIL PROTECTED]>: HI, Ernst, The problem is one of data type size differences between the 64 and 32 bit compilers, I think. See below for details. I have checked and found my email regarding 64 bit Ubuntu and Linrad from last September, and my error messages on compiling Linrad were identical to yours [slight difference in line numbers due to different versions of Linrad]. My notes at the time included: -start quote from September 2006: First errors [in a long list] noted: calibrate.c: In function ?final_filtercorr_init?: calibrate.c:401: warning: format ?%d? expects type ?int?, but argument 3 has type ?long unsigned int? calibrate.c:401: warning: format ?%d? expects type ?int?, but argument 4 has type ?long unsigned int? The statement in question [401] is: sprintf(s,"File size reduced from %d to %d bytes", 5*fft1_size*sizeof(float)+20*sizeof(int), 5*siz*sizeof(float)+20*sizeof(int)); I imagine this will be occurring at other spots as well. I tried a quick [and potentially dangerous] fix by 'casting' the integer as follows: sprintf(s,"File size reduced from %d to %d bytes", (int)(5*fft1_size*sizeof(float)+20*sizeof(int)), (int)(5*siz*sizeof(float)+20*sizeof(int))); This of course just got me the warning: cc1: warnings being treated as errors buf.c: In function ?init_blanker?: buf.c:1364: warning: cast from pointer to integer of different size buf.c:1364: warning: cast to pointer from integer of different size because the compiler didn't like tha cast that was done at: blanker_refpulse=(void*)(((int)(blanker_handle)+15)&0xfff0); -end of note from September 2006. My kernel version and gcc version used at that time are as follows: [EMAIL PROTECTED]:~# uname -a Linux w3sz-amd64 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16 01:50:50 UTC 2006 x86_64 GNU/Linux [EMAIL PROTECTED]:~# gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) [EMAIL PROTECTED]:~# Note that Leif indicated to you that Linrad compiled OK for him with gcc version as recent as 4.1.2 20061115 (Debian). This is newer than the gcc version that failed under 64 OS, so it is not just that our versions of gcc are 'too recent'. The problem is the 64 bit compilation. Leif and I exchanged emails back in September and he pointed out that Linrad assumes the following variable sizes [ILP32]: char: 1 short = short int: 2 int: 4 long = long int: 4 . A little test program he sent me to run showed that the 64 bit gcc compiler I was using [see above for version number] uses the following sizes [LP64]: char 1 short int 2 int 4 long int 8 long unsigned int 8 . I believe this is the problem preventing the compilation of Linrad. Here are a couple of links related to this problem and the porting of C applications from 32 to 64 bits: http://www-128.ibm.com/developerworks/library/l-port64.html http://www.unix.org/version2/whatsnew/lp64_wp.html While in theory one can just tell the gcc compiler to run in 32 bit mode by giving the flag -m32, using the -m32 flag to make the compiler revert to 32 bit mode does NOT work with my gcc/hardware combo. I get the following when I use the -m32 flag: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/bin/ld: cannot find -lc The -m64 bit flag works fine, e.g. "gcc -m64 test.c" works fine [if you want 64 bit code]. It may be that the Ubuntu gcc 64 b