jacob navia wrote:
> santosh wrote:
>> santosh wrote:
>>> Richard Heathfield wrote:
>>>> Malcolm McLean said:
>>>>
>>>> <snip>
>>>>> I haven't thought through the garbage collection issue. However I
>>>>> am not rejecting the idea out of hand on the grounds that Jacob
>>>>> Navia is a Frenchman, or promotes his compiler too vigorously on
>>>>> clc, or likes trading names with Richard Heathfield.
>>>> On that subject, it occurs to me that the topicality threads I
>>>> started last week have now served their purpose, so I'll be
>>>> re-enabling my filter to cut down on some of the noise.
>>>>
>>>> Incidentally, whilst the filter was off, I noted that Mr Navia had
>>>> posted a link to a Linux version of lcc-win32, so I figured I'd do
>>>> a little light testing. I followed the installation instructions,
>>>> such as they are, and couldn't even get "hello, world" to compile.
>>>>
>>>> Maybe it's just me. <shrug>
>>>>
>>>> For the record, the error message I got was:
>>>>
>>>> lcc: error while loading shared libraries: libbfd-2.11.92.0.12.so:
>>>> cannot open shared object file: No such file or directory
>>>>
>>>> The mentioned file is in /usr/local/lib as required. I even copied
>>>> it into /usr/local/bin on the off-chance, but that didn't help.
>>
>> I found a tem****ary fix. Copy the above file to /usr/lib/ and things
>> seem to work. At least a hello world program could be compiled and
>> run.
>>
>> Obviously the implementation has numerous Windows specific
>> assumptions.
>>
>> <snip rest>
>>
>
> Hello Santosh
I've cross-posted this to comp.compilers.lcc and set follow-ups to it.
Hope you don't mind.
> Obviously the shared object must be in your loader path...
> I mean I can't fix that, it is up to the user now, because I did
> not write an installation program yet.
But you could have at least mentioned the issue.
> Obviously too, /usr/lib is "windows specific" :-)
I didn't say that.
> I have worked in that version for months and months.
> An assembler must be written,
Why can't you ****t the assembler that comes with lcc-win32? Or perhaps
use as? Or even emit object code directly?
> and I made the STRATEGIC MISTAKE of
> using libbfd.so, with the assumption that that library
> would be available in the user machine. Nope.
It's not a mistake. You can just list libbfd as a prerequisite for
lcc-linux32. It easy enough to download, compile and install. Besides
it's becoming rather standard under most Linux distributions.
> Besides, the debug information format under linux is different
> than the one I use under windows. Since I can't write a debugger
> now, as I did under windows, I must generate gdb compatible
> debug information. This is done now.
Nice. Are all the command-line switches documented in the user manual
under Windows applicable? I think you should include a small file that
explain which switches are implemented and which are not.
I was rather annoyed to see that the usage message was not available.
What's so system specific about printing a bunch of strings to
stdout? :)
> I am changing the compiler now to use /usr/local/lcc, and added
> following paths to the include search path:
>
> /usr/local/lcc/include
This should almost certainly be /usr/local/include/lcc/
> /usr/local/include
> /usr/include/lcc
> /usr/include
In my opinion you should neatly encapsulate lcc's headers in it's
own 'lcc' sub-directory under the system include directories. That way
you don't need to bother with /usr/include/ and /usr/local/include/
> I will try to write the driver tomorrow
>
> Thanks for your input but please, think on the work
> behind that program
Yes, I understand. I'm pleased that I can try out your compiler natively
under Linux with all the complications of WINE.
|
