Discussion of issues specific to the SWI-Prolog implementation of Prolog.

Liu, Yu | 14 May 00:54

relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

I'm trying to compile 64-bit 5.10.0 release on the following 64-bit platform:

$ uname -a
Linux pa501c1n9 2.6.9-89.0.2.EL.msdw.1largesmp #1 SMP Fri Jun 12 15:15:13 EDT 2009 x86_64

The build is successful. However, when I try to build a lib that links the libswipl.a lib, I got the following error:

ld: ..../lib/libswipl.a(pl-file.o): relocation R_X86_64_PC32 against `unallocStream' can not be used when making a shared object; recompile with -fPIC

I compiled the libswipl.a with -fPIC, but it doesn't help. This flag worked for 5.8.2 release which I experienced similar error, I don't recall the exact error as I did it a while back.

gcc -c -I. -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gcc34_64/ src -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gcc34_64/src/rc -Wall -O3 -fno-strict-aliasing -fPIC -fPIC -fPIC -pthread libtai/caldate_fmjd.c -o libtai/caldate_fmjd.o

Comparing the source code between 5.10.0 and 5.8.2 release, the 'unallocStream' is newly added to 5.10.0 in src/pl-funcs.h.

Can someone help on how to fix this?

NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.

headers

Jan Wielemaker | 16 May 19:42

Re: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

On Thu, 2010-05-13 at 18:54 -0400, Liu, Yu wrote:
> I'm trying to compile 64-bit 5.10.0 release on the following 64-bit
> platform:
>  
> $ uname -a
> Linux pa501c1n9 2.6.9-89.0.2.EL.msdw.1largesmp #1 SMP Fri Jun 12
> 15:15:13 EDT 2009 x86_64
> 
> The build is successful. However, when I try to build a lib that links
> the libswipl.a lib, I got the following error:
>   
> ld: ..../lib/libswipl.a(pl-file.o): relocation R_X86_64_PC32 against
> `unallocStream' can not be used when making a shared object; recompile
> with -fPIC
> 
> I compiled the libswipl.a with -fPIC, but it doesn't help. This flag
> worked for 5.8.2 release which I experienced similar error, I don't
> recall the exact error as I did it a while back. 
>  
> gcc -c -I.
> -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gcc34_64/ src
-I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gcc34_64/src/rc -Wall
-O3 -fno-strict-aliasing -fPIC  -fPIC  -fPIC  -pthread  libtai/caldate_fmjd.c -o libtai/caldate_fmjd.o
> 
> Comparing the source code between 5.10.0 and 5.8.2 release, the
> 'unallocStream' is newly added to 5.10.0 in src/pl-funcs.h.
>  
> Can someone help on how to fix this?

My assumption is that you also have the old version installed and
somehow settings of the PATH/LD_LIBRARY_PATH/SWI_HOME_DIR causes it
to pick the old version's library.

	--- Jan

headers

Liu, Yu | 21 May 00:04

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

The following change fixed my problem. I'm not sure what so special about this unallocStream function.
Anyway, could you provide a fix for this in future patch/release?

edit pl-funcs.h.

   change

      COMMON(void) unallocStream(IOSTREAM *s);

    to

      void pl_unallocStream(IOSTREAM *s);

Note, I renamed the function to avoid potential name clashes with other libs.

Also, on a non-related matter, please increase MAXNEWLINES from 5 to sth larger in pl-read.c. I modified it
to 1024 to cope with atoms that longer than 5 newlines. I pass yaml message as a long atom to prolog. 5 is just
too small.

Thanks,
Yu  

-----Original Message-----
From: Jan Wielemaker [mailto:J.Wielemaker <at> cs.vu.nl] 
Sent: Sunday, May 16, 2010 1:42 PM
To: Liu, Yu (IT)
Cc: swi-prolog <at> iai.uni-bonn.de
Subject: Re: [SWIPL] relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

On Thu, 2010-05-13 at 18:54 -0400, Liu, Yu wrote:
> I'm trying to compile 64-bit 5.10.0 release on the following 64-bit
> platform:
>  
> $ uname -a
> Linux pa501c1n9 2.6.9-89.0.2.EL.msdw.1largesmp #1 SMP Fri Jun 12
> 15:15:13 EDT 2009 x86_64
> 
> The build is successful. However, when I try to build a lib that links 
> the libswipl.a lib, I got the following error:
>   
> ld: ..../lib/libswipl.a(pl-file.o): relocation R_X86_64_PC32 against 
> `unallocStream' can not be used when making a shared object; recompile 
> with -fPIC
> 
> I compiled the libswipl.a with -fPIC, but it doesn't help. This flag 
> worked for 5.8.2 release which I experienced similar error, I don't 
> recall the exact error as I did it a while back.
>  
> gcc -c -I.
> -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gc
> c34_64/ src 
> -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gc
> c34_64/src/rc -Wall -O3 -fno-strict-aliasing -fPIC  -fPIC  -fPIC  
> -pthread  libtai/caldate_fmjd.c -o libtai/caldate_fmjd.o
> 
> Comparing the source code between 5.10.0 and 5.8.2 release, the 
> 'unallocStream' is newly added to 5.10.0 in src/pl-funcs.h.
>  
> Can someone help on how to fix this?

My assumption is that you also have the old version installed and somehow settings of the
PATH/LD_LIBRARY_PATH/SWI_HOME_DIR causes it to pick the old version's library.

	--- Jan

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive
confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and
store emails to the extent permitted by applicable law.

headers

Jan Wielemaker | 21 May 09:17

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

Yu,

Looking at this more carefully, unallocStream() is a *private* function
to the SWI-Prolog library.  It is defined COMMON, which means it is not
exported from the shared lib (a GCC/ELF feature).  You get your a bit
vague message because you try to use it.

However, unallocStream() has *no* meaning when called outside the
kernel.  Calling it will most likely make the system unstable.
So, what does the code of your lib looks like?

On Thu, 2010-05-20 at 18:04 -0400, Liu, Yu wrote:
> The following change fixed my problem. I'm not sure what so special about this unallocStream function.
Anyway, could you provide a fix for this in future patch/release?
> 
> edit pl-funcs.h.
> 
>    change
> 
>       COMMON(void) unallocStream(IOSTREAM *s);
> 
>     to
> 
>       void pl_unallocStream(IOSTREAM *s);
> 
> Note, I renamed the function to avoid potential name clashes with other libs.
> 
> Also, on a non-related matter, please increase MAXNEWLINES from 5 to sth larger in pl-read.c. I modified
it to 1024 to cope with atoms that longer than 5 newlines. I pass yaml message as a long atom to prolog. 5 is
just too small.

Use style_check(-atom).  The limit is intended to enhance error
reporting in sources with many quoted atoms if somewhere a quote
is missing.

It would be nice if Prolog has a better quoted-atom syntax for long
atoms.  E.g. somethings like Pythons """long string""".  Unfortunately
this means the string "long string" in Prolog (at least traditionally;
not sure about ISO here).

	Cheers --- Jan

headers

Liu, Yu | 21 May 15:38

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

Hi Jan,

Thanks for the reply. I didn't call unallocStream anywhere from my lib. The relocation R_X86_64_PC32
error occurred simply when trying to build a shared lib linked with libswipl.a and the error suggested to
recompile libswipl with -fPIC flag which I already did.

style_check(-atom) worked. I must have used it wrongly before. 

Totally agree with you on "It would be nice if Prolog has a better quoted-atom syntax for long atoms". I've
built a yaml_atom_to_list/2 and I could certainly use "better quoted-atom syntax" to avoid skipping
quotes in my parser.

Thanks,
Yu

-----Original Message-----
From: Jan Wielemaker [mailto:J.Wielemaker <at> cs.vu.nl] 
Sent: Friday, May 21, 2010 3:18 AM
To: Liu, Yu (IT)
Cc: swi-prolog <at> iai.uni-bonn.de; Nicos
Subject: RE: [SWIPL] relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

Yu,

Looking at this more carefully, unallocStream() is a *private* function to the SWI-Prolog library.  It is
defined COMMON, which means it is not exported from the shared lib (a GCC/ELF feature).  You get your a bit
vague message because you try to use it.

However, unallocStream() has *no* meaning when called outside the kernel.  Calling it will most likely
make the system unstable.
So, what does the code of your lib looks like?

On Thu, 2010-05-20 at 18:04 -0400, Liu, Yu wrote:
> The following change fixed my problem. I'm not sure what so special about this unallocStream function.
Anyway, could you provide a fix for this in future patch/release?
> 
> edit pl-funcs.h.
> 
>    change
> 
>       COMMON(void) unallocStream(IOSTREAM *s);
> 
>     to
> 
>       void pl_unallocStream(IOSTREAM *s);
> 
> Note, I renamed the function to avoid potential name clashes with other libs.
> 
> Also, on a non-related matter, please increase MAXNEWLINES from 5 to sth larger in pl-read.c. I modified
it to 1024 to cope with atoms that longer than 5 newlines. I pass yaml message as a long atom to prolog. 5 is
just too small.

Use style_check(-atom).  The limit is intended to enhance error reporting in sources with many quoted
atoms if somewhere a quote is missing.

It would be nice if Prolog has a better quoted-atom syntax for long atoms.  E.g. somethings like Pythons
"""long string""".  Unfortunately this means the string "long string" in Prolog (at least
traditionally; not sure about ISO here).

	Cheers --- Jan

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive
confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and
store emails to the extent permitted by applicable law.

headers

Jan Wielemaker | 21 May 16:09

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

On Fri, 2010-05-21 at 09:38 -0400, Liu, Yu wrote:
> Hi Jan,
> 
> Thanks for the reply. I didn't call unallocStream anywhere from my lib. The relocation R_X86_64_PC32
error occurred simply when trying to build a shared lib linked with libswipl.a and the error suggested to
recompile libswipl with -fPIC flag which I already did.

The error message is very misleading, but either your binutils is broken
or you are mixing up things.  Take

#include <SWI-Prolog.h>

int
main(int argc, char **argv)
{ if ( PL_initialise(argc, argv) )
  { PL_toplevel();
    PL_halt(0);
  }

  PL_halt(1);
}

This perfectly compiles and links using

gcc -pthread -o x -I ~/lib/swipl/include t.c
~/lib/swipl/lib/x86_64-linux/libswipl.a -l gmp -lncurses -lreadline -lm
-lrt

This is using Ubuntu 9.10, AMD64

Of course, way simpler is 

	swipl-ld -o x t.c

... but that links against the dynamic library

	--- Jan

> style_check(-atom) worked. I must have used it wrongly before. 
> 
> Totally agree with you on "It would be nice if Prolog has a better quoted-atom syntax for long atoms". I've
built a yaml_atom_to_list/2 and I could certainly use "better quoted-atom syntax" to avoid skipping
quotes in my parser.

I would be a bit surprised if you need long atoms in the source-code to
process YAML messages.  Or are you saying that you have long YAML
messages embedded in your Prolog program?

	--- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

headers

Jan Wielemaker | 21 May 16:09

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

On Fri, 2010-05-21 at 09:38 -0400, Liu, Yu wrote:
> Hi Jan,
> 
> Thanks for the reply. I didn't call unallocStream anywhere from my lib. The relocation R_X86_64_PC32
error occurred simply when trying to build a shared lib linked with libswipl.a and the error suggested to
recompile libswipl with -fPIC flag which I already did.

The error message is very misleading, but either your binutils is broken
or you are mixing up things.  Take

#include <SWI-Prolog.h>

int
main(int argc, char **argv)
{ if ( PL_initialise(argc, argv) )
  { PL_toplevel();
    PL_halt(0);
  }

  PL_halt(1);
}

This perfectly compiles and links using

gcc -pthread -o x -I ~/lib/swipl/include t.c
~/lib/swipl/lib/x86_64-linux/libswipl.a -l gmp -lncurses -lreadline -lm
-lrt

This is using Ubuntu 9.10, AMD64

Of course, way simpler is 

	swipl-ld -o x t.c

... but that links against the dynamic library

	--- Jan

> style_check(-atom) worked. I must have used it wrongly before. 
> 
> Totally agree with you on "It would be nice if Prolog has a better quoted-atom syntax for long atoms". I've
built a yaml_atom_to_list/2 and I could certainly use "better quoted-atom syntax" to avoid skipping
quotes in my parser.

I would be a bit surprised if you need long atoms in the source-code to
process YAML messages.  Or are you saying that you have long YAML
messages embedded in your Prolog program?

	--- Jan

headers

Liu, Yu | 21 May 15:38

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

Hi Jan,

Thanks for the reply. I didn't call unallocStream anywhere from my lib. The relocation R_X86_64_PC32
error occurred simply when trying to build a shared lib linked with libswipl.a and the error suggested to
recompile libswipl with -fPIC flag which I already did.

style_check(-atom) worked. I must have used it wrongly before. 

Totally agree with you on "It would be nice if Prolog has a better quoted-atom syntax for long atoms". I've
built a yaml_atom_to_list/2 and I could certainly use "better quoted-atom syntax" to avoid skipping
quotes in my parser.

Thanks,
Yu

-----Original Message-----
From: Jan Wielemaker [mailto:J.Wielemaker@...] 
Sent: Friday, May 21, 2010 3:18 AM
To: Liu, Yu (IT)
Cc: swi-prolog@...; Nicos
Subject: RE: [SWIPL] relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

Yu,

Looking at this more carefully, unallocStream() is a *private* function to the SWI-Prolog library.  It is
defined COMMON, which means it is not exported from the shared lib (a GCC/ELF feature).  You get your a bit
vague message because you try to use it.

However, unallocStream() has *no* meaning when called outside the kernel.  Calling it will most likely
make the system unstable.
So, what does the code of your lib looks like?

On Thu, 2010-05-20 at 18:04 -0400, Liu, Yu wrote:
> The following change fixed my problem. I'm not sure what so special about this unallocStream function.
Anyway, could you provide a fix for this in future patch/release?
> 
> edit pl-funcs.h.
> 
>    change
> 
>       COMMON(void) unallocStream(IOSTREAM *s);
> 
>     to
> 
>       void pl_unallocStream(IOSTREAM *s);
> 
> Note, I renamed the function to avoid potential name clashes with other libs.
> 
> Also, on a non-related matter, please increase MAXNEWLINES from 5 to sth larger in pl-read.c. I modified
it to 1024 to cope with atoms that longer than 5 newlines. I pass yaml message as a long atom to prolog. 5 is
just too small.

Use style_check(-atom).  The limit is intended to enhance error reporting in sources with many quoted
atoms if somewhere a quote is missing.

It would be nice if Prolog has a better quoted-atom syntax for long atoms.  E.g. somethings like Pythons
"""long string""".  Unfortunately this means the string "long string" in Prolog (at least
traditionally; not sure about ISO here).

	Cheers --- Jan

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive
confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and
store emails to the extent permitted by applicable law.
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

headers

Richard O'Keefe | 25 May 00:20

Re: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform


On May 21, 2010, at 7:17 PM, Jan Wielemaker wrote:
> It would be nice if Prolog has a better quoted-atom syntax for long
> atoms.  E.g. somethings like Pythons """long string""".  Unfortunately
> this means the string "long string" in Prolog (at least traditionally;
> not sure about ISO here).

Edinburgh Prolog syntax for long strings is dead simple:
put a quote at each end, double each internal quote, and you're done.
Here's the code from my text editor 'top' to do it:

void smalltalk_quote_region(void) {
     Char q = (message("quote?"), kb_8());
     if (here > mark) z = here, a = mark;
     else             z = mark, a = here;
     here = mark = z;
     insert(-1, q);
     while (here != a) {
         here--;
         if (fetch(here) == q) insert(-1, q);
     }
     insert(-1, q);
}

So: type whatever long string you want.
Mark one end.  Go to the other end.  ^X"' will wrap quotes around it.
In my experience, the effort is _less_ than the effort of using
Python strings, because absolutely *any* string will work, with no
manual effort required other than indicating each end and what quote
you want.  Oh, and I get to use the same command for
	Prolog
	Smalltalk
	Fortran
If "ease of getting it right" is the criterion, I'd have to say
that DEC-10 Prolog syntax *is* the better syntax for this purpose.
(If you want lots of control characters, not so good, of course.)

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

headers

Richard O'Keefe | 25 May 00:20

Re: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform


On May 21, 2010, at 7:17 PM, Jan Wielemaker wrote:
> It would be nice if Prolog has a better quoted-atom syntax for long
> atoms.  E.g. somethings like Pythons """long string""".  Unfortunately
> this means the string "long string" in Prolog (at least traditionally;
> not sure about ISO here).

Edinburgh Prolog syntax for long strings is dead simple:
put a quote at each end, double each internal quote, and you're done.
Here's the code from my text editor 'top' to do it:

void smalltalk_quote_region(void) {
     Char q = (message("quote?"), kb_8());
     if (here > mark) z = here, a = mark;
     else             z = mark, a = here;
     here = mark = z;
     insert(-1, q);
     while (here != a) {
         here--;
         if (fetch(here) == q) insert(-1, q);
     }
     insert(-1, q);
}

So: type whatever long string you want.
Mark one end.  Go to the other end.  ^X"' will wrap quotes around it.
In my experience, the effort is _less_ than the effort of using
Python strings, because absolutely *any* string will work, with no
manual effort required other than indicating each end and what quote
you want.  Oh, and I get to use the same command for
	Prolog
	Smalltalk
	Fortran
If "ease of getting it right" is the criterion, I'd have to say
that DEC-10 Prolog syntax *is* the better syntax for this purpose.
(If you want lots of control characters, not so good, of course.)

headers

Jan Wielemaker | 21 May 09:17

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

Yu,

Looking at this more carefully, unallocStream() is a *private* function
to the SWI-Prolog library.  It is defined COMMON, which means it is not
exported from the shared lib (a GCC/ELF feature).  You get your a bit
vague message because you try to use it.

However, unallocStream() has *no* meaning when called outside the
kernel.  Calling it will most likely make the system unstable.
So, what does the code of your lib looks like?

On Thu, 2010-05-20 at 18:04 -0400, Liu, Yu wrote:
> The following change fixed my problem. I'm not sure what so special about this unallocStream function.
Anyway, could you provide a fix for this in future patch/release?
> 
> edit pl-funcs.h.
> 
>    change
> 
>       COMMON(void) unallocStream(IOSTREAM *s);
> 
>     to
> 
>       void pl_unallocStream(IOSTREAM *s);
> 
> Note, I renamed the function to avoid potential name clashes with other libs.
> 
> Also, on a non-related matter, please increase MAXNEWLINES from 5 to sth larger in pl-read.c. I modified
it to 1024 to cope with atoms that longer than 5 newlines. I pass yaml message as a long atom to prolog. 5 is
just too small.

Use style_check(-atom).  The limit is intended to enhance error
reporting in sources with many quoted atoms if somewhere a quote
is missing.

It would be nice if Prolog has a better quoted-atom syntax for long
atoms.  E.g. somethings like Pythons """long string""".  Unfortunately
this means the string "long string" in Prolog (at least traditionally;
not sure about ISO here).

	Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

headers

Liu, Yu | 21 May 00:04

RE: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

The following change fixed my problem. I'm not sure what so special about this unallocStream function.
Anyway, could you provide a fix for this in future patch/release?

edit pl-funcs.h.

   change

      COMMON(void) unallocStream(IOSTREAM *s);

    to

      void pl_unallocStream(IOSTREAM *s);

Note, I renamed the function to avoid potential name clashes with other libs.

Also, on a non-related matter, please increase MAXNEWLINES from 5 to sth larger in pl-read.c. I modified it
to 1024 to cope with atoms that longer than 5 newlines. I pass yaml message as a long atom to prolog. 5 is just
too small.

Thanks,
Yu  

-----Original Message-----
From: Jan Wielemaker [mailto:J.Wielemaker@...] 
Sent: Sunday, May 16, 2010 1:42 PM
To: Liu, Yu (IT)
Cc: swi-prolog@...
Subject: Re: [SWIPL] relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

On Thu, 2010-05-13 at 18:54 -0400, Liu, Yu wrote:
> I'm trying to compile 64-bit 5.10.0 release on the following 64-bit
> platform:
>  
> $ uname -a
> Linux pa501c1n9 2.6.9-89.0.2.EL.msdw.1largesmp #1 SMP Fri Jun 12
> 15:15:13 EDT 2009 x86_64
> 
> The build is successful. However, when I try to build a lib that links 
> the libswipl.a lib, I got the following error:
>   
> ld: ..../lib/libswipl.a(pl-file.o): relocation R_X86_64_PC32 against 
> `unallocStream' can not be used when making a shared object; recompile 
> with -fPIC
> 
> I compiled the libswipl.a with -fPIC, but it doesn't help. This flag 
> worked for 5.8.2 release which I experienced similar error, I don't 
> recall the exact error as I did it a while back.
>  
> gcc -c -I.
> -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gc
> c34_64/ src 
> -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gc
> c34_64/src/rc -Wall -O3 -fno-strict-aliasing -fPIC  -fPIC  -fPIC  
> -pthread  libtai/caldate_fmjd.c -o libtai/caldate_fmjd.o
> 
> Comparing the source code between 5.10.0 and 5.8.2 release, the 
> 'unallocStream' is newly added to 5.10.0 in src/pl-funcs.h.
>  
> Can someone help on how to fix this?

My assumption is that you also have the old version installed and somehow settings of the
PATH/LD_LIBRARY_PATH/SWI_HOME_DIR causes it to pick the old version's library.

	--- Jan

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive
confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and
store emails to the extent permitted by applicable law.
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

headers

Jan Wielemaker | 16 May 19:42

Re: relocation R_X86_64_PC32 error when compiling 5.10.0 on linux x86_64 platform

On Thu, 2010-05-13 at 18:54 -0400, Liu, Yu wrote:
> I'm trying to compile 64-bit 5.10.0 release on the following 64-bit
> platform:
>  
> $ uname -a
> Linux pa501c1n9 2.6.9-89.0.2.EL.msdw.1largesmp #1 SMP Fri Jun 12
> 15:15:13 EDT 2009 x86_64
> 
> The build is successful. However, when I try to build a lib that links
> the libswipl.a lib, I got the following error:
>   
> ld: ..../lib/libswipl.a(pl-file.o): relocation R_X86_64_PC32 against
> `unallocStream' can not be used when making a shared object; recompile
> with -fPIC
> 
> I compiled the libswipl.a with -fPIC, but it doesn't help. This flag
> worked for 5.8.2 release which I experienced similar error, I don't
> recall the exact error as I did it a while back. 
>  
> gcc -c -I.
> -I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gcc34_64/ src
-I/var/tmp/build.yuliu/prolog/swi/5.10.0/x86_64.linux.2.6.glibc.2.3/gcc34_64/src/rc -Wall
-O3 -fno-strict-aliasing -fPIC  -fPIC  -fPIC  -pthread  libtai/caldate_fmjd.c -o libtai/caldate_fmjd.o
> 
> Comparing the source code between 5.10.0 and 5.8.2 release, the
> 'unallocStream' is newly added to 5.10.0 in src/pl-funcs.h.
>  
> Can someone help on how to fix this?

My assumption is that you also have the old version installed and
somehow settings of the PATH/LD_LIBRARY_PATH/SWI_HOME_DIR causes it
to pick the old version's library.

	--- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog