Hello there,
I have the following error when compiling pike 7.2.570 on freebsd sparc64 :
Compiling peep_t.c /usr/ports/lang/pike72/work/pike-7.2.570/src/smartlink cc -I. -I/usr/ports/lang/pike72/work/pike-7.2.570/src -I/usr/local/include -I/usr/ports/lang/pike72/work/pike-7.2.570/src -O -pthread -R/usr/local/lib -L/usr/local/lib -rdynamic language.o security.o bignum.o interpret.o constants.o cpp.o fdlib.o cyclic.o array.o backend.o callback.o encode.o docode.o dynamic_buffer.o dynamic_load.o error.o fd_control.o fsort.o gc.o hashtable.o lex.o multiset.o signal_handler.o pike_search.o pike_types.o main.o mapping.o pike_memory.o module.o module_support.o object.o opcodes.o operators.o port.o program.o rusage.o stralloc.o stuff.o threads.o version.o queue.o builtin.o svalue.o las_t.o builtin_functions_t.o peep_t.o `cat modules/linker_options` -lm -lcrypt -o tpike svalue.o(.text+0x23bc): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x2428): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x28a0): In function `is_lt': : undefined reference to `_Qp_cmp' gmake[3]: *** [tpike-real] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/pike72/work/pike-7.2.570/src' gmake[2]: *** [/usr/ports/lang/pike72/work/pike-7.2.570/src/tpike] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/pike72/work/pike-7.2.570/src' gmake[1]: *** [pike] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/pike72/work/pike-7.2.570/src'
Can you tell me where is this comming from ?
FYI :
bash-2.05b# uname -a FreeBSD ws02.local.oav.net 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Mon Nov 8 09:50:23 CET 2004 root@ws02.local.oav.net:/usr/src/sys/sparc64/compile/WPHP01 sparc64 bash-2.05b# gcc -v Using built-in specs. Configured with: FreeBSD/sparc64 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728
/Xavier -- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
In the last episode (Nov 08), Xavier Beaudouin said:
I have the following error when compiling pike 7.2.570 on freebsd sparc64 :
Compiling peep_t.c svalue.o(.text+0x23bc): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x2428): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x28a0): In function `is_lt': : undefined reference to `_Qp_cmp'
Can you tell me where is this comming from ?
Are you building with --with-long-double-precision?
It looks like gcc has decided to use a function call to implement a long double compare, but the function was never implemented. Could you see if you can generate a minimal testcase that produces this error? Something like
main() { long double a = 1.0; long double b = 2.0; return (a<b); }
possibly with different types for a or b, or a different comparison operator. I had someone try this particular testcase with a -current box, and it linked a _Qp_flt function instead of _Qp_cmp. I did a quick search and couldn't really determine where the _Qp_flt or _Qp_cmp functions are supposed to come from...
Le 8 nov. 04, à 18:07, Dan Nelson a écrit :
In the last episode (Nov 08), Xavier Beaudouin said:
I have the following error when compiling pike 7.2.570 on freebsd sparc64 :
Compiling peep_t.c svalue.o(.text+0x23bc): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x2428): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x28a0): In function `is_lt': : undefined reference to `_Qp_cmp'
Can you tell me where is this comming from ?
Are you building with --with-long-double-precision?
Yes I am using :
--with-thread-library=${PTHREAD_LIBS} \ --with-double-precision \ --with-long-double-precision \
Do you think this the culprit?
It looks like gcc has decided to use a function call to implement a long double compare, but the function was never implemented. Could you see if you can generate a minimal testcase that produces this error? Something like
main() { long double a = 1.0; long double b = 2.0; return (a<b); }
possibly with different types for a or b, or a different comparison operator. I had someone try this particular testcase with a -current box, and it linked a _Qp_flt function instead of _Qp_cmp. I did a quick search and couldn't really determine where the _Qp_flt or _Qp_cmp functions are supposed to come from...
Ok I'll do that RSN (tomorrow morning because I am not able to join my FreeBSD 5.3 sparc64 machines here) and give you the results.
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
In the last episode (Nov 08), Xavier Beaudouin said:
Le 8 nov. 04, à 18:07, Dan Nelson a écrit :
In the last episode (Nov 08), Xavier Beaudouin said:
I have the following error when compiling pike 7.2.570 on freebsd sparc64 :
Compiling peep_t.c svalue.o(.text+0x23bc): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x2428): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x28a0): In function `is_lt': : undefined reference to `_Qp_cmp'
Can you tell me where is this comming from ?
Are you building with --with-long-double-precision?
Yes I am using :
--with-thread-library=${PTHREAD_LIBS} \ --with-double-precision \ --with-long-double-precision \Do you think this the culprit?
Probably. My guess is that when the FreeBSD sparc64 port was done, the developers forgot about one of the glue functions required by the sparc64 ABI. If you can get a small testcase to prove there's a problem it should be easy to get it fixed.
Le 8 nov. 04, à 21:30, Mirar @ Pike developers forum a écrit :
--with-double-precision \ --with-long-double-precision \That's a bit contradictive. Choose one. ;)
Yes it is... Now this is fixed on port... Only i386 machines have --with-long-double-precision (which was the culprit on this OS).
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
Le 8 nov. 04, à 18:07, Dan Nelson a écrit :
In the last episode (Nov 08), Xavier Beaudouin said:
I have the following error when compiling pike 7.2.570 on freebsd sparc64 :
Compiling peep_t.c svalue.o(.text+0x23bc): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x2428): In function `is_lt': : undefined reference to `_Qp_cmp' svalue.o(.text+0x28a0): In function `is_lt': : undefined reference to `_Qp_cmp'
Can you tell me where is this comming from ?
Are you building with --with-long-double-precision?
Yes removing it fixed that problem.
It looks like gcc has decided to use a function call to implement a long double compare, but the function was never implemented. Could you see if you can generate a minimal testcase that produces this error? Something like
main() { long double a = 1.0; long double b = 2.0; return (a<b); }
I have just tryed this on my sparc machine and this work like a charm... No compilation error or whatever...
Maybe on such machines --with-long-double-precision shoud not be applied ?
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
In the last episode (Nov 10), Xavier Beaudouin said:
Le 8 nov. 04, à 18:07, Dan Nelson a écrit :
In the last episode (Nov 08), Xavier Beaudouin said:
I have the following error when compiling pike 7.2.570 on freebsd sparc64 :
Compiling peep_t.c svalue.o(.text+0x23bc): In function `is_lt': : undefined reference to `_Qp_cmp'
Can you tell me where is this comming from ?
It looks like gcc has decided to use a function call to implement a long double compare, but the function was never implemented. Could you see if you can generate a minimal testcase that produces this error? Something like
main() { long double a = 1.0; long double b = 2.0; return (a<b); }
I have just tryed this on my sparc machine and this work like a charm... No compilation error or whatever...
Right. This particular testcase works; I should have mentioned that I had someone with a FreeBSD/sparc64 system try it for me. It ends up calling _Qp_flt (the less-than comparison function). The problem is, I don't know in which cases gcc generates a generic compare (_Qp_cmp), but apparently something does. I've filed a bugreport on it and included a pointer to NetBSD's libc, since it looks like they have implemented all the functions. It's PR sparc64/73782.
Maybe on such machines --with-long-double-precision shoud not be applied ?
Well, a better fix would be to add the appropriate functions to libc :)
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
Mirar ＠ Pike developers forum -
Xavier Beaudouin