Hello,

I'm new to this list (and to Free Pascal...)

What are the news from bug #6618 (ex 4733), on building shared libraries on a x86_64 architecture? http://www.freepascal.org/mantis/view.php?id=6618

I did some tests, and it seems to bee still present in 2.0.2 and current 2.1.1 snapshot (I encountered no problems with i386). In the BTS I see that the status is still new,open, and there seems to have been no activity on this bug since its submission.

I also had a look at the thread "Hitting bug 4733" on this list http://lists.freepascal.org/lists/fpc-devel/2006-April/007514.html and to http://community.freepascal.org:10000/bboards/message?message_id=152498&forum_id=24083 in the forums (AMD64 shared library link problem)

Has anybody had a look at it?
If yes, does it seem to be hard to fix?
Is it the PIC generation that is broken for x86_64? Please tell me if there are any plans on the matter. I'm quite willing to help, but would appreciate a little help...

Thanks a lot,

Dominique Leducq

The problem is that we don't want to compile the default rtl with PIC.

Is it the PIC generation that is broken for x86_64?

Afaik not.

Please tell me if there are any plans on the matter. I'm quite willing to help, but would appreciate a little help...

You simply need to rebuild the rtl with PIC.

[Dominique Leducq]

Well, I already tried that with 2.0.2 : make rtl "OPT=-Cg" (is that right ?), but it didn't work (yes, I checked that the right system unit was used by the linker) I will try again with 2.1.1

I had nothing to recompile to make it work with i386 linux: is the default RTL compiled with PIC for i386? If so, why not for x86_64? I know that there are performances losses with PIC, but I thought that this losses where lessened with x86_64 arch?

Well, I already tried that with 2.0.2 : make rtl "OPT=-Cg" (is that right ?), but it didn't work (yes, I checked that the right system unit was used by the linker) I will try again with 2.1.1

So it works with 2.1.1 when recompiling the RTL with -Cg.

Now when I try to link the resulting library with a C program, I encounter symbol definition problems :

$ gcc -o test2 test2.o -L. -lsoTest3
./libsoTest3.so: undefined reference to `__stkptr' ./libsoTest3.so: undefined reference to `_haltproc' ./libsoTest3.so: undefined reference to `operatingsystem_parameter_argc' ./libsoTest3.so: undefined reference to `operatingsystem_parameter_argv' collect2: ld returned 1 exit status

where libsoTest3.so is the shared library built with Free Pascal

I found that this symbols are defined in the loaders ({c,g,}prt0.o), but when I link with those, i get :

$ LC_ALL=C gcc -o test2 test2.o gprt0.o -L. -lsoTest3 gprt0.o: In function `_start':
(.text+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/crt1.o:../sysdeps/x86_64/elf/start.S:65: first defined here gprt0.o: In function `data_start':
(.data+0x0): multiple definition of `__data_start' /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/crt1.o:(.data+0x0): first defined here collect2: ld returned 1 exit status

How may I avoid this symbol conflict ?

Thanks,

Dominique Leducq

I guess it doesn't work completely in 2.0.3

I had nothing to recompile to make it work with i386 linux: is the default RTL compiled with PIC for i386?

No, PIC isn't necessary for i386 shared libs. In theory, they aren't necessary for x86_64 shared libs either but the linux loader/linker can't handle this.