Menu
▾
▴
clisp-devel
|
From: Anton V. <avo...@ya...> - 2011-07-11 22:46:35
Attachments:
make.out
|
Hello.
I am trying to build on Windows 7 using cygwin. I did
./configure build-dir
cd build-dir
make
It fails.
If I call make again, it fails. The make output is attached.
One of the interesting peaces of this output
checking for CLISP linking set... missing lisp.a lispinit.mem modules.h modules.o makevars
The files lisp.a, lispinit.mem, modules.h, modules.o, makevars do exists in build-dir and in the build-dir/boot
Best regards,
- Anton |
|
From: Sam S. <sd...@gn...> - 2011-07-13 15:11:00
|
Hi,
> * Anton Vodonosov <nib...@ln...> [2011-07-12 02:46:26 +0400]:
>
> checking for CLISP linking set... missing lisp.a lispinit.mem modules.h modules.o makevars
1. please do
$ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)'
2. please edit the failing configure; find this section:
cl_cv_clisp_linkset=`dirname ${cl_cv_clisp_linkset}`
missing=''
# cf. src/clisp-link.in:check_linkset (we do not need to check for
# lisp.run because cl_cv_clisp_linkset comes from SYS::PROGRAM-NAME)
for f in lisp.a lispinit.mem modules.h modules.o makevars; do
test -r "${cl_cv_clisp_linkset}/$f" || missing=${missing}' '$f
done
and add
echo cl_cv_clisp_linkset=$cl_cv_clisp_linkset
before and after cl_cv_clisp_linkset is set; and also
pwd
ls
thanks!
--
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://memri.org http://dhimmi.com http://www.PetitionOnline.com/tap12009/
http://jihadwatch.org http://thereligionofpeace.com http://www.memritv.org
It's not just a language, it's an adventure. Common Lisp.
|
|
From: Anton V. <avo...@ya...> - 2011-07-13 16:42:55
|
13.07.2011, 19:10, "Sam Steingold" <sd...@gn...>: > Hi, > >> * Anton Vodonosov <nib...@ln...>; [2011-07-12 02:46:26 +0400]: >> >> checking for CLISP linking set... missing lisp.a lispinit.mem modules.h modules.o makevars > > 1. please do > $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)' $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)' "lisp.exe" > 2. please edit the failing configure; find this section: Doing that, result will follow. |
|
From: Anton V. <avo...@ya...> - 2011-07-13 17:00:40
Attachments:
make.out.2
|
13.07.2011, 19:10, "Sam Steingold" <sd...@gn...>:
>
> 2. please edit the failing configure; find this section:
>
> cl_cv_clisp_linkset=`dirname ${cl_cv_clisp_linkset}`
> missing=''
> # cf. src/clisp-link.in:check_linkset (we do not need to check for
> # lisp.run because cl_cv_clisp_linkset comes from SYS::PROGRAM-NAME)
> for f in lisp.a lispinit.mem modules.h modules.o makevars; do
> test -r "${cl_cv_clisp_linkset}/$f" || missing=${missing}' '$f
> done
>
> and add
> echo cl_cv_clisp_linkset=$cl_cv_clisp_linkset
> before and after cl_cv_clisp_linkset is set; and also
> pwd
> ls
>
The code in the clisp\modules\i18n\configure now looks like:
echo '***** check point 1 *******'
echo cl_cv_clisp_linkset=$cl_cv_clisp_linkset
echo pwd=`pwd`
echo ls:
ls
echo '***** end check point 1 *******'
cl_cv_clisp_linkset=`$cl_cv_clisp -q -norc -x '(sys::program-name)' 2>/dev/null | sed -e 's/^"//' -e 's/"$//'`
echo '***** check point 2 *******'
echo cl_cv_clisp_linkset=$cl_cv_clisp_linkset
echo pwd=`pwd`
echo ls:
ls
echo '***** end checkpoint 2 *******'
cl_cv_clisp_linkset=`dirname ${cl_cv_clisp_linkset}`
echo '***** check point 3 *******'
echo cl_cv_clisp_linkset=$cl_cv_clisp_linkset
echo pwd=`pwd`
echo ls:
ls
echo '***** end checkpoint 3 *******'
missing=''
The make output is attached.
Best regards,
- Anton |
|
From: Sam S. <sd...@gn...> - 2011-07-13 19:17:11
|
> * Anton Vodonosov <nib...@ln...> [2011-07-13 20:42:47 +0400]:
>
> $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)'
> "lisp.exe"
OK, this is a bug and the cause of all the rest of your woes.
could you please run the above in gdb, set a breakpoint in find_executable()
and see why it does not put the full patch into executable_name.
Apparently, GetModuleFileName puts "lisp.exe" into execname (execname.c:67).
Is that the case?
does this patch fix the problem?
======================================================
diff -r 34301ca4e079 src/execname.c
--- a/src/execname.c Wed Jul 13 11:03:32 2011 -0400
+++ b/src/execname.c Wed Jul 13 15:12:51 2011 -0400
@@ -63,11 +63,15 @@ int find_executable (const char * progra
if (executable_name != NULL) return 0;
#if defined(WIN32_NATIVE)
{ /* an illustration that win32 API can be sometimes useful */
- char execname[MAX_PATH];
+ char execname[MAX_PATH], fullname[MAX_PATH];
+ DWORD len;
if (!GetModuleFileName(NULL,execname,MAX_PATH))
goto notfound;
- executable_name = (char*)malloc(strlen(execname)+1);
- strcpy(executable_name,execname);
+ len = GetFullPathName(execname,MAX_PATH,fullname,NULL);
+ if (len <= 0)
+ goto notfound;
+ executable_name = (char*)malloc(len+1);
+ strcpy(executable_name,fullname);
return 0; }
#elif defined(UNIX)
#if defined(UNIX_LINUX) || defined(UNIX_CYGWIN32)
======================================================
--
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://www.PetitionOnline.com/tap12009/ http://pmw.org.il
http://ffii.org http://jihadwatch.org http://www.memritv.org
Daddy, why doesn't this magnet pick up this floppy disk?
|
|
From: Anton V. <avo...@ya...> - 2011-07-14 00:06:28
|
13.07.2011, 23:17, "Sam Steingold" <sd...@gn...>:
>> * Anton Vodonosov <nib...@ln...>; [2011-07-13 20:42:47 +0400]:
>>
>> $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)'
>> "lisp.exe"
>
> OK, this is a bug and the cause of all the rest of your woes.
> could you please run the above in gdb, set a breakpoint in find_executable()
> and see why it does not put the full patch into executable_name.
> Apparently, GetModuleFileName puts "lisp.exe" into execname (execname.c:67).
> Is that the case?
No, you are looking at different piece of code. I am on cygwin.
See
#elif defined(UNIX)
#if defined(UNIX_LINUX) || defined(UNIX_CYGWIN32)
and below.
I tested with gdb. This code is executed:
if (realpath(program_name,executable_name) == NULL) {
free(executable_name); goto notfound;
}
Why realpath(program_name,executable_name) returns NULL?
I am not sure (it's inconvenient to debug when you are not used to gdb), but I see that
it enter the function defined at src/pathname.d, line 58:
#define realpath my_realpath /* avoid conflict with Consensys realpath declaration */
local char* realpath (const char* path, char* resolved_path) {
...
If you read the comment above the function: "...on some other systems,
notably on cygwin, we _do_ need the system implementation of realpath
because otherwise we get screwed..."
So on cygwin, we need to use system implementation of realpath,
instead of our own defined in pathname.d (actually called my_realpath).
I am finishing with it for today, because it's late. Probably this info will give you a clue
to the error. Otherwise I will need to learn gdb better to debug this.
Best regards,
- Anton
|
|
From: Sam S. <sd...@gn...> - 2011-07-14 12:47:37
|
> * Anton Vodonosov <nib...@ln...> [2011-07-14 04:06:17 +0400]: > > 13.07.2011, 23:17, "Sam Steingold" <sd...@gn...>: >>> * Anton Vodonosov <nib...@ln...>; [2011-07-13 20:42:47 +0400]: >>> >>> $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)' >>> "lisp.exe" >> >> OK, this is a bug and the cause of all the rest of your woes. >> could you please run the above in gdb, set a breakpoint in find_executable() >> and see why it does not put the full patch into executable_name. > > Otherwise I will need to learn gdb better to debug this. please do. thanks. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://www.PetitionOnline.com/tap12009/ http://camera.org http://thereligionofpeace.com http://openvotingconsortium.org Politically Correct Chess: Translucent VS. Transparent. |
|
From: Anton V. <avo...@ya...> - 2011-07-14 12:54:15
|
14.07.2011, 16:47, "Sam Steingold" <sd...@gn...>: >> * Anton Vodonosov <nib...@ln...>; [2011-07-14 04:06:17 +0400]: >> >> 13.07.2011, 23:17, "Sam Steingold" <sd...@gn...>;: >>>> * Anton Vodonosov <nib...@ln...>;; [2011-07-13 20:42:47 +0400]: >>>> >>>> $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)' >>>> "lisp.exe" >>> OK, this is a bug and the cause of all the rest of your woes. >>> could you please run the above in gdb, set a breakpoint in find_executable() >>> and see why it does not put the full patch into executable_name. >> Otherwise I will need to learn gdb better to debug this. > > please do. > thanks. I will try later. But is it OK that the system defined realpath() function is not used, and the CLISP my_realpath() is used instead? |
|
From: Sam S. <sd...@gn...> - 2011-07-14 15:03:48
|
> * Anton Vodonosov <nib...@ln...> [2011-07-14 16:54:04 +0400]: > > 14.07.2011, 16:47, "Sam Steingold" <sd...@gn...>: >>> * Anton Vodonosov <nib...@ln...>; [2011-07-14 04:06:17 +0400]: >>> >>> 13.07.2011, 23:17, "Sam Steingold" <sd...@gn...>;: >>>>> * Anton Vodonosov <nib...@ln...>;; [2011-07-13 20:42:47 +0400]: >>>>> >>>>> $ ./lisp.exe -q -norc -M lispinit.mem -x '(sys::program-name)' >>>>> "lisp.exe" >>>> OK, this is a bug and the cause of all the rest of your woes. >>>> could you please run the above in gdb, set a breakpoint in find_executable() >>>> and see why it does not put the full patch into executable_name. >>> Otherwise I will need to learn gdb better to debug this. >> >> please do. >> thanks. > > I will try later. But is it OK that the system defined realpath() function is not used, and > the CLISP my_realpath() is used instead? are you sure this is the case? $ grep HAVE_REALPATH config.h $ nm lisp.exe | grep my_realpath (gdb) br my_realpath -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://honestreporting.com http://mideasttruth.com http://iris.org.il http://dhimmi.com http://ffii.org http://palestinefacts.org You cannot fire me. Slaves are not fired. Slaves are sold. |
|
From: Anton V. <avo...@ya...> - 2011-07-14 18:07:48
|
14.07.2011, 19:03, "Sam Steingold" <sd...@gn...>: >> I will try later. But is it OK that the system defined realpath() function is not used, and >> the CLISP my_realpath() is used instead? > > are you sure this is the case? > $ grep HAVE_REALPATH config.h > $ nm lisp.exe | grep my_realpath > (gdb) br my_realpath > Yes, it is. $ grep HAVE_REALPATH config.h [nothing] $ nm lisp.exe | grep my_realpath 0042aee0 t _my_realpath (gdb) br my_realpath Breakpoint 18 at 0x42aefa: file ../src/pathname.d, line 61. Best regards, - Anton |
|
From: Sam S. <sd...@gn...> - 2011-07-14 19:13:23
|
> * Anton Vodonosov <nib...@ln...> [2011-07-14 22:07:37 +0400]: > > $ grep HAVE_REALPATH config.h > [nothing] __OUCH___!!! this means that we are not checking for realpath at all. no wonder ... (fixed, sorry). -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://openvotingconsortium.org http://dhimmi.com http://jihadwatch.org http://ffii.org http://pmw.org.il Sinners can repent, but stupid is forever. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X