Re: Kylix support

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-16 03:53:31

Felix E. Klee wrote:
>>Debian Linux. It just grabs system includes. 
> 
> 
> Hm, I don't know what you mean by that. People using RedHat 8 have been 
> reporting problems with include files on the Kylix newsgroups. IIRC, a 
> solution that works for some projects is to put /usr/include as the first 
> item in the include path. Of course, this will cause header files in 
> /usr/include to have a higher precedence than those provided by Kylix, and 
> you might get new problems.

OK, I'll look into the problem later.

>>>>BTW, how shared libraries work on Kylix? In the same was as for ordinary
>>>>Linux/gcc?
>>>
>>>Well, first of all, as you might guess, the ABI of Kylix and gcc shared
>>>C++ library is different. Maybe that will change with version 4 of Kylix
>>>(I heard that the gcc 3.2 ABI is becoming some kind of standard). So,
>>>Kylix shared libraries cannot be linked with ld. One needs to use Kylix
>>>ilink instead (or maybe bc++, but I haven't tried that).
>>
>>Do the need any import libraries? Or just ".so" in the linker command line?
> 
> 
> I'm not sure whether I understand what you mean. Here's an example for an 
> ilink invocation to create a shared object:
> 
> ilink \ 
> -Tpd -aa -D"" -x -Gn -v \
> -Ltmp:/Net/hubble/Users/felix/local/lib/kylix3//lib/obj \
> -L/Net/hubble/Users/felix/local/lib/kylix3//lib:/usr/lib:/lib \
> -L/usr/X11R6/lib:/Net/hubble/Users/felix/local/lib/kylix3//bin \
> borinitso.o foo.o, libfoo.so,, \
> libborcrtl.so libborstl.so libborunwind.so libc.so libm.so libdl.so,, \
> foo.res
> 
> The above lines come straight from Kylix. I created a new shared object 
> project called foo and exported the corresponding Makefile using the 
> "Project->Export Makefile" menu item in the IDE. Then I called "make -f 
> foo.mak" and copied and beautified the lines showing the ilink invocation.

OK, I see "so" files in command line and that what I was asking for. On 
Windows, you'd have to create "import library" from DLL and use the import
library on the linker command line. That's additional complexity.

>>>However, be aware that the Kylix
>>>generated shared libraries somehow are "unstable" and cause runtime
>>>errors and segfaults in applications using them. You'll find a couple of
>>>bug reports concering these issues on Borland's Quality Central. Note
>>>that, for whatever reason, static libraries seem to work flawlessly.
>>
>>Cool. We have shared linking by default :-) Anyway, if shared libs are
>>unsuable, it's easier for us now.
> 
> 
> Eh? Why is it easier then?

Because we can declare shared libs unsupported for now :-)
But since there are used in the way you've described above, there's no need 
for that. No problems.

- Volodya