Is it possible to make libgpc.a a shared lib? If so how do I go about it?
If not why not?
I didn't find a answer in the doc's so I'm asking here.
Thanks Richard
Richard D. Jackson wrote:
Is it possible to make libgpc.a a shared lib? If so how do I go about it?
I've only tested it under Linux so far. There's no "official" support, and configure doesn't support it, but adding `WITH_SHARED=yes' on the make command line should work.
I suppose other systems might need some different options etc. in the makefile. If you provide them, I'll happily accept them, but I don't have the time now to do any debugging or give further advice there.
There's a small bug, in rts/Makefile.in, gpc_minor must be 1 (will be fixed in the next version).
Note that the RTS interface might change with each GPC version, so the shared lib will have to be rebuilt for each one (and the old ones kept if you have any exetuables using them).
Frank
Frank Heckenbach writes:
Note that the RTS interface might change with each GPC version, so the shared lib will have to be rebuilt for each one (and the old ones kept if you have any exetuables using them).
That could be better for a shared library. Maybe you can decouple the shared object name from the gpc version and only increase the soname, iff the ABI changes in an incompatible way? If that's not possible, maybe mark the ChangeLog entries with "libgpc ABI change", as upstream gcc does with g++.
Matthias
Matthias Klose wrote:
Frank Heckenbach writes:
Note that the RTS interface might change with each GPC version, so the shared lib will have to be rebuilt for each one (and the old ones kept if you have any exetuables using them).
That could be better for a shared library. Maybe you can decouple the shared object name from the gpc version and only increase the soname, iff the ABI changes in an incompatible way? If that's not possible, maybe mark the ChangeLog entries with "libgpc ABI change", as upstream gcc does with g++.
If you have a solution that doesn't involve additional work for me, I'm all ears ... ;-)
Note that not only changes in the RTS sources can cause such incompatibilities, but also some changes in the compiler internals (built-in types, parameter passing conventions, ...), and missing one means hard to find bugs, i.e. time wasted with debugging (which I don't want to do if I can avoid it).
Frank
A few observations from trying out gpc (Linux).
1. --interface-only -c doesn't (always) produce a .o as the docs say, but rather only a .gpi (and a .gpm in the case of modules), at least in my case. Either that, or its placing the object files somewhere else on my system! In turn, this seems to block me from compiling with units or modules unless I use --autobuild on the main program to force the issue, so to speak.
2. The blocksize parameter to reset() appears not to be optional (as the doc says it is) if the file is untyped. It'd be nice if there was a 'silent default' so that existing programs work 'as is'. For example reset( infile, infname ) ; gives a syntax error and demands that a buffer size be added.
3. One of my enumerated types contains 'property' and 'operator' which prove to be GPC reserved words of some sort as the compiler throws up a syntax error. I don't really want to have to alter these... are these keywords part of some new standard? (that's new as in, in the last 10 years!) There is no info. in the doc.: both are "under construction".
4. It'd be nice to sort the command-line options. They are hard to locate as they are without trawling through the whole list.
5. The index on the left of the PDF format seems to always "point" to immediately _after_ the item, rather than to the item (minor quibble).
6. While I appreciate the effort that has been made, personally, I don't consider projects complete until the docs have been written... it seems to me much of the doc. at present is just a shell, full of '(Under construction)'! It would make a huge difference if some of the people who know how things are supposed to be filled in the odd gap...
Where is the original (text) document format? Is it the HTML format? I might try poke the odd bit in myself.
Can I suggest that a scheme allowing user's to add comments/observations to the docs be made so that at least some information gets into the docs. while the implementors have their minds elsewhere? Perhaps add some keyword to indicate that this item/section has been written by a user rather than implementor? For example perhaps bracketing the text in the spirit of the way that XML does, so that the reader can easily identify which bits have been contributed by users and thus while probably true need to be taken with a little salt :-)
Alternatively add another section "user's observations" or some such to the description of each element.
It might also prove a useful reference of when user's experiences are at odds with the implementors intentions while a bug fix is pending.
Really the implementors ought to be using something like HeaderDoc or whatever and write these descriptions as they code... just a thought...
Grant
On Mon, 2003-01-27 at 03:36, Grant Jacobs wrote:
A few observations from trying out gpc (Linux).
<snip>
- While I appreciate the effort that has been made, personally, I
don't consider projects complete until the docs have been written... it seems to me much of the doc. at present is just a shell, full of '(Under construction)'! It would make a huge difference if some of the people who know how things are supposed to be filled in the odd gap...
I couldn't agree with you more.
Where is the original (text) document format? Is it the HTML format? I might try poke the odd bit in myself.
It is in texinfo format in the ./p/doc/[lang] directory. also it seems some of the doc is generated as well.
Can I suggest that a scheme allowing user's to add comments/observations to the docs be made so that at least some information gets into the docs. while the implementors have their minds elsewhere? Perhaps add some keyword to indicate that this item/section has been written by a user rather than implementor? For example perhaps bracketing the text in the spirit of the way that XML does, so that the reader can easily identify which bits have been contributed by users and thus while probably true need to be taken with a little salt :-)
Alternatively add another section "user's observations" or some such to the description of each element.
It might also prove a useful reference of when user's experiences are at odds with the implementors intentions while a bug fix is pending.
A gpc wiki would fit the bill for such a setup.
Really the implementors ought to be using something like HeaderDoc or whatever and write these descriptions as they code... just a thought...
Again I agree with you. I have only been able to find pasdoc but it was wrote for delphi/kylix/fpc which means the code may not be portable to gpc. It also has not been touched in a couple of years. I grabed a copy of the source and am going to take a look at getting it ported to gpc and add some things to it. For instance right now it will output HTML and Texi. The HTML part is OK but I will need to work on the Texi part and change it to texinfo as that is what is being used for gpc. I may actualy just end up rewriting it from scratch as it is using quite a few custom class that duplicate units gpc already has and I would prefer to use the ones gpc provides verses costom ones.
Richard
Grant Jacobs wrote:
A few observations from trying out gpc (Linux).
- --interface-only -c doesn't (always) produce a .o as the docs
say,
Where does it say so? Oh, you mean in the `-c' description. OK, the `--interface-only' description should make it clearer that it overrides `-c' in this regard. (To me, "compiling the interface" is clear enough to mean producing only a gpi file, but probably not to everyone ... ;-)
but rather only a .gpi (and a .gpm in the case of modules), at least in my case.
I think that's reasonable behaviour, and the docs should be adjusted.
Either that, or its placing the object files somewhere else on my system! In turn, this seems to block me from compiling with units or modules unless I use --autobuild on the main program to force the issue, so to speak.
Maybe you misunderstand the purpose of the option. It means to process only the interface part of a unit/module. Of course, you generally don't get a complete program without the implementation.
`--interface-only' is only useful (necessary) in situations with circular unit/module dependencies, e.g., A's interface uses B, and B's implementation uses A. The only way to compile this is to first compile B with `--interface-only', then A and B again without the option.
- The blocksize parameter to reset() appears not to be optional (as
the doc says it is)
: Reset : : Like @samp{Rewrite}, @samp{Append} and @samp{Extend} do, : @samp{Reset} accepts an optional second and third parameter for the : name of the file in the filesystem and, for untyped files, the block : size of the file. (For details, see @ref{Rewrite}.)
: Rewrite : : The last optional parameter determines the block size of the file. : It is valid only for untyped files. Almost always, 1 is the most : reasonable value here. However, the existence of this parameter is a : BP compatibility feature, and in BP it defaults to 128 because of : historic misdesign. Therefore, GPC requires this parameter to be : present. In @samp{--borland-pascal} mode, it makes it optional (like : BP does), but warns about the strange default if omitted.
I admit, it could have been made a little clearer ;-), and if you or someone wants to help on the documentation, that's always welcome.
if the file is untyped. It'd be nice if there was a 'silent default' so that existing programs work 'as is'. For example reset( infile, infname ) ; gives a syntax error and demands that a buffer size be added.
Yes, it's be nice, but BP stands in the way, as noted above. (AFAIK, the misdesign goes back to UCSD Pascal and the CPM file system ...) I think it would be too confusing to have two different silent defaults, depending on the dialect option.
The only thing I could possibly imagine would be to make the difference clear in some other way, e.g. to have the file declared as `file of Void' or so (with a default of 1), whereas a simple `file' (as in BP) behaves as it does now.
- One of my enumerated types contains 'property' and 'operator'
which prove to be GPC reserved words of some sort as the compiler throws up a syntax error. I don't really want to have to alter these... are these keywords part of some new standard?
`property' is from Delphi, `operator' from PXSC.
Generally, if you don't want any extensions (which include a few new keywords, of course), try `--extended-pascal'.
The next GPC will also support `--disable-keyword=property,operator' (or `{$disable-keyword=property operator}' in the source).
- It'd be nice to sort the command-line options. They are hard to
locate as they are without trawling through the whole list.
OTOH, they are (somewhat) sorted by topic now.
Well, we could have one list as it is now, and another one in alphabetic order with the same information.
Since the list is generated automatically, this should be rather easy to do. But would it help, or be more confusing?
- The index on the left of the PDF format seems to always "point" to
immediately _after_ the item, rather than to the item (minor quibble).
This might be a problem in texinfo.tex. In the texi source, the index items are defined as `@cindex'. If they're put before the start of a "node", the index in Info gets wrong (points to the previous node). So they have to be put after it, as is done now, which apparently causes this behaviour in TeX. We could report it and hope that someone will fix it ...
- While I appreciate the effort that has been made, personally, I
don't consider projects complete until the docs have been written...
I don't think anyone would consider GPC complete in any way. ;-)
Where is the original (text) document format? Is it the HTML format? I might try poke the odd bit in myself.
It is in texinfo format in the ./p/doc/[lang] directory. also it seems some of the doc is generated as well.
Yep -- for the units, that's currently just a copy of their interface part, and some other information (list of options and keywords) is extracted from the compiler sources.
Can I suggest that a scheme allowing user's to add comments/observations to the docs be made so that at least some information gets into the docs. while the implementors have their minds elsewhere? Perhaps add some keyword to indicate that this item/section has been written by a user rather than implementor? For example perhaps bracketing the text in the spirit of the way that XML does, so that the reader can easily identify which bits have been contributed by users and thus while probably true need to be taken with a little salt :-)
Alternatively add another section "user's observations" or some such to the description of each element.
It might also prove a useful reference of when user's experiences are at odds with the implementors intentions while a bug fix is pending.
A gpc wiki would fit the bill for such a setup.
I'm somewhat skeptical. There have been a number of other suggestions over the years to address the "formal issues", but in many cases, the potential contributors lost interest or had no time to spend shortly after (or even before) the formalities had been settled.
In the end, it really comes down to the fact that someone has to write the stuff ...
Actually, it's not a big issue for me to apply documentation changes I get (and to review them for serious mistakes) -- a simple patch sent to me or the gpc-doc list will do. I've been getting some up to now -- but unfortunately too sporadic and by far not enough to really cover the holes ...
So I suggest to focus on the content first, not on the formalities. Of course, if there are several contributors you might want to agree on the areas you work on to avoid overlaps (though the chances are small, given the number of holes) ...
Really the implementors ought to be using something like HeaderDoc or whatever and write these descriptions as they code... just a thought...
Again I agree with you. I have only been able to find pasdoc but it was wrote for delphi/kylix/fpc which means the code may not be portable to gpc. It also has not been touched in a couple of years. I grabed a copy of the source and am going to take a look at getting it ported to gpc and add some things to it. For instance right now it will output HTML and Texi. The HTML part is OK but I will need to work on the Texi part and change it to texinfo as that is what is being used for gpc.
I've made some plans for such a utility, in particular some features required, and some ideas for the syntax.
My main goal would be (unlike some -- I don't know if all -- of the other utilities), to have the syntax as simple and readable as possible, e.g. to use paired quotes (like `foo') for markup (which would be @samp{foo} in texi). The purpose would explicitely *not* be to have a complete layout system (such as TeX; I think already texi is not), but to focus on the common things. (There can always be an escape mode for the occasional exception.)
In the end, the existing comments in the unit interfaces, where they exists, should be accepted with few modifications, and the output should replace the interface copies in p/doc/generated.
If there is some real interest, I could write my ideas (which now are just some random notes).
I may actualy just end up rewriting it from scratch as it is using quite a few custom class that duplicate units gpc already has and I would prefer to use the ones gpc provides verses costom ones.
BTW, I don't quite see where such a utility would need classes and collections and all that stuff at all, but then, I'm only a moderate OOP follower ...
Frank
On Mon, 2003-01-27 at 20:04, Frank Heckenbach wrote: <big snip>
Again I agree with you. I have only been able to find pasdoc but it was wrote for delphi/kylix/fpc which means the code may not be portable to gpc. It also has not been touched in a couple of years. I grabed a copy of the source and am going to take a look at getting it ported to gpc and add some things to it. For instance right now it will output HTML and Texi. The HTML part is OK but I will need to work on the Texi part and change it to texinfo as that is what is being used for gpc.
I've made some plans for such a utility, in particular some features required, and some ideas for the syntax.
My main goal would be (unlike some -- I don't know if all -- of the other utilities), to have the syntax as simple and readable as possible, e.g. to use paired quotes (like `foo') for markup (which would be @samp{foo} in texi). The purpose would explicitely *not* be to have a complete layout system (such as TeX; I think already texi is not), but to focus on the common things. (There can always be an escape mode for the occasional exception.)
In the end, the existing comments in the unit interfaces, where they exists, should be accepted with few modifications, and the output should replace the interface copies in p/doc/generated.
If there is some real interest, I could write my ideas (which now are just some random notes).
pasdoc, the tool I'm looking at was modeled after javadoc syntax. I personaly prefer more of a perl POD type syntax. Other words I would prefer to keep it simple. complex stuff just ends up not being used. the simple stuff that works gets used.
And yes I would love to see what your ideas are. As I would really prefer to know what everyone wants before starting to work on it. I would hate to spend the time to write something that no one but myself would use when there are others that would use it if only I had spent a little extra effort to get their input up front.
I may actualy just end up rewriting it from scratch as it is using quite a few custom class that duplicate units gpc already has and I would prefer to use the ones gpc provides verses costom ones.
BTW, I don't quite see where such a utility would need classes and collections and all that stuff at all, but then, I'm only a moderate OOP follower ...
OOP would make some things easer to do. For instance in the case of pasdoc it creates a document class that handles all of the parsing of the source files. Then a output class is pluged into the doc class to make the finished docs. Yes you can do something simular with out using OOP but OOP provides a more eligant solution to the problem. It also makes it easy to plug new output backends in with out affecting the main body of code.
Richard D. Jackson wrote:
On Mon, 2003-01-27 at 20:04, Frank Heckenbach wrote:
<big snip> > > > > Again I agree with you. I have only been able to find pasdoc but it was > > wrote for delphi/kylix/fpc which means the code may not be portable to > > gpc. It also has not been touched in a couple of years. I grabed a copy > > of the source and am going to take a look at getting it ported to gpc > > and add some things to it. For instance right now it will output HTML > > and Texi. The HTML part is OK but I will need to work on the Texi part > > and change it to texinfo as that is what is being used for gpc. > > I've made some plans for such a utility, in particular some features > required, and some ideas for the syntax. > > My main goal would be (unlike some -- I don't know if all -- of the > other utilities), to have the syntax as simple and readable as > possible, e.g. to use paired quotes (like `foo') for markup (which > would be @samp{foo} in texi). The purpose would explicitely *not* be > to have a complete layout system (such as TeX; I think already texi > is not), but to focus on the common things. (There can always be an > escape mode for the occasional exception.) > > In the end, the existing comments in the unit interfaces, where they > exists, should be accepted with few modifications, and the output > should replace the interface copies in p/doc/generated. > > If there is some real interest, I could write my ideas (which now > are just some random notes). > pasdoc, the tool I'm looking at was modeled after javadoc syntax. I personaly prefer more of a perl POD type syntax. Other words I would prefer to keep it simple. complex stuff just ends up not being used. the simple stuff that works gets used.
And yes I would love to see what your ideas are. As I would really prefer to know what everyone wants before starting to work on it.
I don't know POD, but I agree to the "keep it simple" principle. :-)
I just noticed that I started such a thing long time ago. I'm attaching it. But it's just a skeleton yet -- the whole markup stuff is missing. My ideas are put in the top comment of the file (which is longer than the rest of the code ;-). It may already be more complex than what's really needed.
The most difficult bits (and the ones where the program will be most helpful) will probably be, besides the extracting of the comments in the first place, the generation of cross-references.
I may actualy just end up rewriting it from scratch as it is using quite a few custom class that duplicate units gpc already has and I would prefer to use the ones gpc provides verses costom ones.
BTW, I don't quite see where such a utility would need classes and collections and all that stuff at all, but then, I'm only a moderate OOP follower ...
OOP would make some things easer to do. For instance in the case of pasdoc it creates a document class that handles all of the parsing of the source files. Then a output class is pluged into the doc class to make the finished docs. Yes you can do something simular with out using OOP but OOP provides a more eligant solution to the problem. It also makes it easy to plug new output backends in with out affecting the main body of code.
I agree to the last point. I'm not sure about the former. I don't see a need for "polymorphism" there, neither for multiple instances -- if the program will support translation of multiple files (not really necessary IMHO since it will usually be run from the Makefile, and it can just as well call it once per file -- in fact, it would do so, aynway, to keep track of dependencies), but even then they would be processed one after another, not simultaneously ...
With only a single instance and without polymorphism, an object class is basically the same as a unit/module.
Frank
On Tue, 2003-01-28 at 22:41, Frank Heckenbach wrote:
Richard D. Jackson wrote:
On Mon, 2003-01-27 at 20:04, Frank Heckenbach wrote:
<snip>
I've made some plans for such a utility, in particular some features required, and some ideas for the syntax.
My main goal would be (unlike some -- I don't know if all -- of the other utilities), to have the syntax as simple and readable as possible, e.g. to use paired quotes (like `foo') for markup (which would be @samp{foo} in texi). The purpose would explicitely *not* be to have a complete layout system (such as TeX; I think already texi is not), but to focus on the common things. (There can always be an escape mode for the occasional exception.)
In the end, the existing comments in the unit interfaces, where they exists, should be accepted with few modifications, and the output
If to get what I/we want means that the existing comments need to change I'm more than willing to do it. The only unit that will be difficult or time consuming to do will the the RTS unit. But still I willing to do the work to get good well formated and cross referanced doc's.
should replace the interface copies in p/doc/generated.
What I envioson is more of a tag syntax verses a complete layout system. By tag I mean something that indicates that something is: Author name Module version copyright notice description return type/description ( may or may not need this ) paramiter code example header ( by this I mean module header or description ) referance index this for later cross referance ect... But not a whole lot of stuff. Leave formating and structure up to the output code. This is how POD, JavaDoc ( core stuff that is ) and a few others do. That way if you don't like the output you can write your own output generator that will format it the way you want. Core Doxygen does this as well but becasue the backend dictates the output form/layout it has had many output generaters created for it. But I think its down fall is that it does allow the programmer to use or embed form/layout stuff for specific output generaters which means the programmer spends can spend too much time trying to do some special form/layout verses just writing the doc. POD on the other had basicly has taken the stance that this is all you get and if you don't like it write your own output module to get what you want. This means that it has sacrificed flexablity for conformance to a standard. And do you know something Perl code is some of the best documented code out there. Which is why I want to follow the perl lead but mostlikly not the format itself. Mostly becase POD does contain some format/layout command in it as well. I really don't want to worry about format/layout when I document code.
What I intend to do before writing any code is to write a specification which I will run by here for comments before writing any code. As I would rather have input and some kind of agrement that it is what we want.
If there is some real interest, I could write my ideas (which now are just some random notes).
pasdoc, the tool I'm looking at was modeled after javadoc syntax. I personaly prefer more of a perl POD type syntax. Other words I would prefer to keep it simple. complex stuff just ends up not being used. the simple stuff that works gets used.
And yes I would love to see what your ideas are. As I would really prefer to know what everyone wants before starting to work on it.
I don't know POD, but I agree to the "keep it simple" principle. :-)
I just noticed that I started such a thing long time ago. I'm attaching it. But it's just a skeleton yet -- the whole markup stuff is missing. My ideas are put in the top comment of the file (which is longer than the rest of the code ;-). It may already be more complex than what's really needed.
The most difficult bits (and the ones where the program will be most helpful) will probably be, besides the extracting of the comments in the first place, the generation of cross-references.
See further down...
I may actualy just end up rewriting it from scratch as it is using quite a few custom class that duplicate units gpc already has and I would prefer to use the ones gpc provides verses costom ones.
BTW, I don't quite see where such a utility would need classes and collections and all that stuff at all, but then, I'm only a moderate OOP follower ...
OOP would make some things easer to do. For instance in the case of pasdoc it creates a document class that handles all of the parsing of the source files. Then a output class is pluged into the doc class to make the finished docs. Yes you can do something simular with out using OOP but OOP provides a more eligant solution to the problem. It also makes it easy to plug new output backends in with out affecting the main body of code.
I agree to the last point. I'm not sure about the former. I don't see a need for "polymorphism" there, neither for multiple instances -- if the program will support translation of multiple files (not really necessary IMHO since it will usually be run from the Makefile, and it can just as well call it once per file -- in fact, it would do so, aynway, to keep track of dependencies), but even then they would be processed one after another, not simultaneously ...
With only a single instance and without polymorphism, an object class is basically the same as a unit/module.
Frank
First the question I would have is what is the target application of the documenter? If for only documenting single monolithic units then a single pass ( single file ) tool would do the job. But on the other hand if you want to handle multi-module/unit applications that need to beable to cross link the documention and or have a unified cross-referance amogst all the code modules then what you really want to do is process all of the files in a single pass. And for doing this OOP will be very helpfull. One other thing I would like for it to do besides output the documentation is to output a cross referance list so that other modules can referance the doc if needed. For instance lets say I'm writing a string utility unit wouldn't it be nice if I could referance the RTS with in my doc's and actualy have a working link to the RTS doc for a paricular function/procedure verses something like this " see these functions in the RTS documentation ....."
I thought this was moving over to gpc-doc? Should I send my postings which I've held back until sorting a hiccup registering for gpc-doc here instead? (more below)
At 1:30 AM -0600 30/1/03, Richard D. Jackson wrote:
On Tue, 2003-01-28 at 22:41, Frank Heckenbach wrote:
Richard D. Jackson wrote:
[snip]
What I envioson is more of a tag syntax verses a complete layout system. By tag I mean something that indicates that something is: Author name Module version copyright notice description return type/description ( may or may not need this ) paramiter code example header ( by this I mean module header or description ) referance index this for later cross referance ect... But not a whole lot of stuff. Leave formating and structure up to the output code. This is how POD, JavaDoc ( core stuff that is ) and a few others do. That way if you don't like the output you can write your own output generator that will format it the way you want. Core Doxygen does this as well but becasue the backend dictates the output form/layout it has had many output generaters created for it. But I think its down fall is that it does allow the programmer to use or embed form/layout stuff for specific output generaters which means the programmer spends can spend too much time trying to do some special form/layout verses just writing the doc. POD on the other had basicly has taken the stance that this is all you get and if you don't like it write your own output module to get what you want. This means that it has sacrificed flexablity for conformance to a standard. And do you know something Perl code is some of the best documented code out there. Which is why I want to follow the perl lead but mostlikly not the format itself. Mostly becase POD does contain some format/layout command in it as well. I really don't want to worry about format/layout when I document code.
What I intend to do before writing any code is to write a specification which I will run by here for comments before writing any code. As I would rather have input and some kind of agrement that it is what we want.
Sounds as if we have been thinking along similar lines. I have my own with notes somewhere on my system...
I agree with leaving formatting to later. You could generate XML and then downstream users could use CSS for layout, for example.
Don't include format per se, but include some style class information like 'header' 'text' etc so that it can be appropriately formatted later.
[big snip; us documentation types write a bit... :-) !]
First the question I would have is what is the target application of the documenter? If for only documenting single monolithic units then a single pass ( single file ) tool would do the job. But on the other hand if you want to handle multi-module/unit applications that need to beable to cross link the documention and or have a unified cross-referance amogst all the code modules then what you really want to do is process all of the files in a single pass. And for doing this OOP will be very helpfull. One other thing I would like for it to do besides output the documentation is to output a cross referance list so that other modules can referance the doc if needed. For instance lets say I'm writing a string utility unit wouldn't it be nice if I could referance the RTS with in my doc's and actualy have a working link to the RTS doc for a paricular function/procedure verses something like this " see these functions in the RTS documentation ....."
Its a good point, but I think processing all the files in a single pass has exactly the same flaw as compiling code in the same fashion. The interface/implementation approach was developed for that reason. I have some thoughts about this, but perhaps they make the doc application too complex for an initial version, so I'll hold off for now.
Grant
On Thu, 2003-01-30 at 02:27, Grant Jacobs wrote:
I thought this was moving over to gpc-doc? Should I send my postings which I've held back until sorting a hiccup registering for gpc-doc here instead? (more below)
At 1:30 AM -0600 30/1/03, Richard D. Jackson wrote:
On Tue, 2003-01-28 at 22:41, Frank Heckenbach wrote:
Richard D. Jackson wrote:
This is the last post on this subject going to gpc. On this one I just did a reply and forgot to move it to gpc-doc.
Richard
On Sun, 2003-01-26 at 05:35, Matthias Klose wrote:
Frank Heckenbach writes:
Note that the RTS interface might change with each GPC version, so the shared lib will have to be rebuilt for each one (and the old ones kept if you have any exetuables using them).
That could be better for a shared library. Maybe you can decouple the shared object name from the gpc version and only increase the soname, iff the ABI changes in an incompatible way? If that's not possible, maybe mark the ChangeLog entries with "libgpc ABI change", as upstream gcc does with g++.
Matthias
I would think that you could just make the so name the release date. Like: libgpc-20021128.so and make non alpha releases like this: libgpc-2.1.so
The problem will be in getting the right name to the linker. Which may mean some changes to the compiler. But I have no clue as to how much work that would be.
Richard
Richard D. Jackson wrote:
On Sun, 2003-01-26 at 05:35, Matthias Klose wrote:
Frank Heckenbach writes:
Note that the RTS interface might change with each GPC version, so the shared lib will have to be rebuilt for each one (and the old ones kept if you have any exetuables using them).
That could be better for a shared library. Maybe you can decouple the shared object name from the gpc version and only increase the soname, iff the ABI changes in an incompatible way? If that's not possible, maybe mark the ChangeLog entries with "libgpc ABI change", as upstream gcc does with g++.
Matthias
I would think that you could just make the so name the release date. Like: libgpc-20021128.so and make non alpha releases like this: libgpc-2.1.so
Currently the name will be something like libgpc.so.2.1.20030127
The problem will be in getting the right name to the linker. Which may mean some changes to the compiler. But I have no clue as to how much work that would be.
That's done using a symlink to libgpc.so (so `-lgpc' will just work if it's found) and `-Wl,-soname=...' (so at runtime the correct one will be used) -- the latter option might not work everywhere, I'm not sure ...
Frank
On Mon, 2003-01-27 at 00:04, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip>
That's done using a symlink to libgpc.so (so `-lgpc' will just work if it's found) and `-Wl,-soname=...' (so at runtime the correct one will be used) -- the latter option might not work everywhere, I'm not sure ...
Frank
Yes a symlink will do the job but when you update the libgpc.so will point to the new lib which will be wrong for old code. I will have to look at the '-Wl,-soname=...' option as didn't know about that one. If it makes the runtime use the correct lib verses just libgpc.so then that will be great.
Richard
Richard D. Jackson wrote:
On Mon, 2003-01-27 at 00:04, Frank Heckenbach wrote:
Richard D. Jackson wrote:
<snip> > That's done using a symlink to libgpc.so (so `-lgpc' will just work > if it's found) and `-Wl,-soname=...' (so at runtime the correct one > will be used) -- the latter option might not work everywhere, I'm > not sure ... > > Frank
Yes a symlink will do the job but when you update the libgpc.so will point to the new lib which will be wrong for old code. I will have to look at the '-Wl,-soname=...' option as didn't know about that one. If it makes the runtime use the correct lib verses just libgpc.so then that will be great.
Yes, the option gives the name stored in the library and then (at compile time) in the executable to be used at run time while the symlink is used only at compile time. So the process goes like this:
- linker searches for `-lgpc' (using `-L' paths), finds libgpc.so, a symlink to libgpc.so.2.1.20030127
- linker opens this file, gets the version number from it which also happens to be libgpc.so.2.1.20030127 and stores it into the executable
- executable searches for libgpc.so.2.1.20030127 (using $LD_LIBRARY_PATH)
If everything works properly, this scheme ensures that different versions of a library and executables using them can exist in parallel. The symlink determines which one is used for newly compiled programs.
Frank
On Sat, 2003-01-25 at 17:59, Frank Heckenbach wrote:
Richard D. Jackson wrote:
Is it possible to make libgpc.a a shared lib? If so how do I go about it?
I've only tested it under Linux so far. There's no "official" support, and configure doesn't support it, but adding `WITH_SHARED=yes' on the make command line should work.
Great I will try that out. I'm on a linux system so I hope it works.
I suppose other systems might need some different options etc. in the makefile. If you provide them, I'll happily accept them, but I don't have the time now to do any debugging or give further advice there.
There's a small bug, in rts/Makefile.in, gpc_minor must be 1 (will be fixed in the next version).
Note that the RTS interface might change with each GPC version, so the shared lib will have to be rebuilt for each one (and the old ones kept if you have any exetuables using them).
Not a problem. I will just rename the lib to libgpc-20021128.so and pass that to the linker on the command line and see if it works. Even though right now that will not be big deal later it might be.
richard
Richard D. Jackson wrote:
Is it possible to make libgpc.a a shared lib?
I noticed that "hello" is quite large on Mac OS X with the non-shared libgpc.a and libgcc.a. It's 666 KB unstripped, 255 KB stripped. Did I miss something ? How large is it on other platforms ?
Regards,
Adriaan van Os
----------
[G4:~/gnu/testgpc/demos] adriaan% uname -v Darwin Kernel Version 6.3: Sat Dec 14 03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC
[G4:~/gnu/testgpc/demos] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-3.2.1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d3 Thread model: single gpc version 20021128, based on gcc-3.2.1
[G4:~/gnu/testgpc/demos] adriaan% gpc -o hello.o -c hello.pas [G4:~/gnu/testgpc/demos] adriaan% gpc -o hello -Wl,-dynamic hello.pas [G4:~/gnu/testgpc/demos] adriaan% ls -l hello* -rwxr-xr-x 1 adriaan staff 682540 Jan 27 13:17 hello -rw-r--r-- 1 adriaan staff 2564 Jan 27 13:09 hello.o -rw-r--r-- 1 adriaan staff 259 Sep 30 14:39 hello.pas
[G4:~/gnu/testgpc/demos] adriaan% gpc -o hello -Wl,-s hello.pas /usr/bin/ld: can't use -s with input files containg indirect symbols (output file must contain at least global symbols, for maximum stripping use -x) collect2: ld returned 1 exit status
[G4:~/gnu/testgpc/demos] adriaan% gpc -o hello -Wl,-x hello.pas [G4:~/gnu/testgpc/demos] adriaan% ls -l hello* -rwxr-xr-x 1 adriaan staff 261060 Jan 27 13:16 hello -rw-r--r-- 1 adriaan staff 2564 Jan 27 13:09 hello.o -rw-r--r-- 1 adriaan staff 259 Sep 30 14:39 hello.pas
Adriaan van Os wrote:
Richard D. Jackson wrote:
Is it possible to make libgpc.a a shared lib?
I noticed that "hello" is quite large on Mac OS X with the non-shared libgpc.a and libgcc.a. It's 666 KB unstripped, 255 KB stripped. Did I miss something ? How large is it on other platforms ?
[G4:~/gnu/testgpc/demos] adriaan% gpc -o hello.o -c hello.pas [G4:~/gnu/testgpc/demos] adriaan% gpc -o hello -Wl,-dynamic hello.pas [G4:~/gnu/testgpc/demos] adriaan% ls -l hello* -rwxr-xr-x 1 adriaan staff 682540 Jan 27 13:17 hello -rw-r--r-- 1 adriaan staff 2564 Jan 27 13:09 hello.o -rw-r--r-- 1 adriaan staff 259 Sep 30 14:39 hello.pas
[G4:~/gnu/testgpc/demos] adriaan% gpc -o hello -Wl,-s hello.pas /usr/bin/ld: can't use -s with input files containg indirect symbols (output file must contain at least global symbols, for maximum stripping use -x) collect2: ld returned 1 exit status
[G4:~/gnu/testgpc/demos] adriaan% gpc -o hello -Wl,-x hello.pas [G4:~/gnu/testgpc/demos] adriaan% ls -l hello* -rwxr-xr-x 1 adriaan staff 261060 Jan 27 13:16 hello -rw-r--r-- 1 adriaan staff 2564 Jan 27 13:09 hello.o -rw-r--r-- 1 adriaan staff 259 Sep 30 14:39 hello.pas
That's normal (without a shared RTS). Same here (Linux/IA32):
frank@goedel:~/work>gpc x.p frank@goedel:~/work>ls -l a.out -rwx------ 1 frank users 624043 Jan 28 01:20 a.out frank@goedel:~/work>gpc -s x.p frank@goedel:~/work>ls -l a.out -rwx------ 1 frank users 324956 Jan 28 01:20 a.out
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Richard D. Jackson wrote:
Is it possible to make libgpc.a a shared lib?
I noticed that "hello" is quite large on Mac OS X with the non-shared libgpc.a and libgcc.a. It's 666 KB unstripped, 255 KB stripped. Did I miss something ? How large is it on other platforms ?
That's normal (without a shared RTS). Same here (Linux/IA32):
I wonder if "ld" is an optimizing linker, as "nohello" has the same executable size as "hello".
Regards,
Adriaan van Os
-------------
[G4:~/gnu/testgpc/adriaan] adriaan% cat nohello.pas
program NoHello; begin end.
[G4:~/gnu/testgpc/adriaan] adriaan% gpc -c -o hello.o hello.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c -o nohello.o nohello.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o hello hello.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o nohello nohello.pas
[G4:~/gnu/testgpc/adriaan] adriaan% ls -l hello* -rwxr-xr-x 1 adriaan staff 682540 Jan 28 11:49 hello -rw-r--r-- 1 adriaan staff 2564 Jan 28 11:48 hello.o -rw-r--r-- 1 adriaan staff 259 Jan 28 11:46 hello.pas
[G4:~/gnu/testgpc/adriaan] adriaan% ls -l nohello* -rwxr-xr-x 1 adriaan staff 682540 Jan 28 11:49 nohello -rw-r--r-- 1 adriaan staff 1956 Jan 28 11:48 nohello.o -rw-r--r-- 1 adriaan staff 29 Jan 28 11:42 nohello.pas
Adriaan van Os wrote:
I wonder if "ld" is an optimizing linker, as "nohello" has the same executable size as "hello".
That's interesting -- doesn't happen here. It might be the result of padding (though 600 bytes seems a little much), I don't know. BTW, is this GNU ld, or an Apple linker?
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
I wonder if "ld" is an optimizing linker, as "nohello" has the same executable size as "hello".
That's interesting -- doesn't happen here. It might be the result of padding (though 600 bytes seems a little much), I don't know.
Maybe, a segment size of 1K or 2K or something like that. The "writeln" and "console" runtime library stuff will be linked in anyway, I guess, because of messages to standard error ?
BTW, is this GNU ld, or an Apple linker?
It's an Apple Mach-O linker. I will download the GNU linker to experiment with.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
I wonder if "ld" is an optimizing linker, as "nohello" has the same executable size as "hello".
That's interesting -- doesn't happen here. It might be the result of padding (though 600 bytes seems a little much), I don't know.
Maybe, a segment size of 1K or 2K or something like that. The "writeln" and "console" runtime library stuff will be linked in anyway, I guess, because of messages to standard error ?
Yes. Only the object file size difference should matter.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
I wonder if "ld" is an optimizing linker, as "nohello" has the same executable size as "hello".
That's interesting -- doesn't happen here. It might be the result of padding (though 600 bytes seems a little much), I don't know.
Maybe, a segment size of 1K or 2K or something like that. The "writeln" and "console" runtime library stuff will be linked in anyway, I guess, because of messages to standard error ?
I found that the default for the segment size is the system's page size (currently 4K on PowerPC).
BTW, is this GNU ld, or an Apple linker?
It's an Apple Mach-O linker. I will download the GNU linker to experiment with.
Still, there must be something wrong with or strange about libgpc.a. Have a look at this:
[G4:~/gnu/testgpc/adriaan] adriaan% cat empty.pas program empty;begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c -o empty.o empty.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o empty_automake empty.pas [G4:~/gnu/testgpc/adriaan] adriaan% set libpath = /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ [G4:~/gnu/testgpc/adriaan] adriaan% ld empty.o /usr/lib/crt1.o -L$libpath -lgpc -lgcc -lSystem -o empty_ld [G4:~/gnu/testgpc/adriaan] adriaan% ld empty.o /usr/lib/crt1.o -L$libpath -lgpc -lgcc -lSystem -all_load -o empty_ld_all [G4:~/gnu/testgpc/adriaan] adriaan% ls -l empty* -rw-r--r-- 1 adriaan staff 1956 Jan 29 22:41 empty.o -rw-r--r-- 1 adriaan staff 25 Jan 29 22:26 empty.pas -rwxr-xr-x 1 adriaan staff 682540 Jan 29 22:41 empty_automake -rwxr-xr-x 1 adriaan staff 682540 Jan 29 22:42 empty_ld -rwxr-xr-x 1 adriaan staff 971336 Jan 29 22:42 empty_ld_all
The hand-linked "empty_ld" has the same size as the autolinked "empty_automake". The executable "empty_ld_all" is larger, because it contains all symbols from the static libraries libgpc.a and libgcc.a (System is a dynamic lib).
Now, have a look at the symbol tables.
[G4:~/gnu/testgpc/adriaan] adriaan% nm empty_ld > empty_ld.sym.txt [G4:~/gnu/testgpc/adriaan] adriaan% nm empty_ld_all > empty_ld_all.sym.txt
If we compare both symbol tables in a text editor, we see that (1) both contain exactly the same number of _p_ entries (from libgpc.a) and (2) both contain a different number of entries from libgcc.a.
Conclusions (1) the linker does optimize usage of libgcc routines (2) the linker does not optimize usage of libgpc routines
So, why doesn't the linker optimize usage of libgpc routines (skipping unreferenced symbols) ?
[The rest of this email is more or less speculation. Please, correct me if I am wrong]
From reading "ld" docs, I got the impression that "ld" cannot optimize per Symbol, but only per Section in a Segment. If this is true, I consider it a grave limitation of "ld".
So, I hope I am wrong, but let's assume it is true. It implies that if only one Symbol in a Segment-Section is referenced, the whole Segment-Section will be linked in. Now, if we further assume that all code in a Pascal unit or module gets into one Segment-Section, including its initialization code (that always gets called) ..... all linker optimizations have automatically gone.
One solution would be to put unit-initialization code in separate segments, a more drastic solution to put all groups of routines or even all routines in different segments.
Regards,
Adriaan van Os
Adriaan van Os wrote:
So, why doesn't the linker optimize usage of libgpc routines (skipping unreferenced symbols) ?
Your "speculation" is correct.
[The rest of this email is more or less speculation. Please, correct me if I am wrong]
From reading "ld" docs, I got the impression that "ld" cannot optimize per Symbol, but only per Section in a Segment. If this is true, I consider it a grave limitation of "ld".
Depends. It assumes some things about the code to optimize by symbols. I've seen code which jumps around in strange ways where this would break. Such code is probably not typical compiler output (but I guess producible using hand-coded `asm' statements), so it would at least have to be an optional feature. I don't know if there are more obstacles (i.e., the object code assumes the integrity of segments in some implicit way).
So, I hope I am wrong, but let's assume it is true. It implies that if only one Symbol in a Segment-Section is referenced, the whole Segment-Section will be linked in. Now, if we further assume that all code in a Pascal unit or module gets into one Segment-Section, including its initialization code (that always gets called) ..... all linker optimizations have automatically gone.
Exactly.
One solution would be to put unit-initialization code in separate segments,
Wouldn't help much since it calls other routines.
a more drastic solution to put all groups of routines or even all routines in different segments.
Yes. C libraries achieve this by putting each function in a separate source file. For me, that's out of the question, since it makes the code hard to maintain and blows it up substantially (if only by the duplicated license notes, but also because many things need to be global which are unit-local now). I have rather strong opinions about this ...
However, there are the options `--function-sections' and `--data-sections'. While they alone don't seem to enable smart linking (at least wheen I tried it on Linux/IA32), they might allow processing of the object files using the binutils (objdump, objcopy) to split it into several files (and combine them into an `.a' archive). It should be possible to automate this, though it might not be exactly trivial to write an appropriate script to do so ...
Frank