[Aldor-l] different libraries that contain files with same name

[Laurentiu Dragan]

Christian Aistleitner wrote:
 > Hello,
 >
 > On Wed, 28 Nov 2007 18:15:41 +0100, Laurentiu Dragan 
<ldragan at aldor.org>
 > wrote:
 >
 >> Ralf Hemmecke wrote:
 >>> It's hypothetical, but imagine you buy a big aldor library from one
 >>> company and another one from another company.
 >>> Both work on non-intersecting areas and have no domain in common.
 >>> You have written a big program that uses both of these libraries.
 >>> Now, for some reason, one company renames a file to foo.ao so that
 >>> (accidently) it agrees with the name of a file in the other library.
 >>> What would you do if you realize that you've spent lots of money to
 >>> develop your program, lots of money for the two libraries and now you
 >>> cannot use both libraries to build the program you want?
 >>>
 >>> Even in an opensource development model that is an unacceptable
 >>> restriction.
 >> That's why companies should use some sort of prefix. If they have the
 >> same prefix, then the libraries are incompatible.
 >
 > I haven't ever come across source code from companies, which used a 
prefix
 > in _filenames_ to get differently _named_ object files.

That's because in most programming languages the name of the file 
containing the code is not used by the generated code.

 >
 > Can you name an example of such a source code? Or is this this just a
 > noble wish?

I think that companies would use a method to avoid name collisions if 
they would know that the filename is used as an identifier for the 
library. Some companies writing software in Java put their code in 
packages (they know that this is a way avoid name conflicts).

My solution was a workaround the current implementation of libraries in 
Aldor. If someone wants to write a library that can be used with other 
libraries, he/she should consider adding a prefix to the filenames. This 
only applies to Aldor; there is no point in doing this in Java, and I 
really don't know many companies writing software in Aldor to give examples.

 >
 >> What if I write two functions "foo" in C and put each one in a different
 >> library. Can you use both functions from the same C source file?
 >
 > You are comparing apples to oranges.
 >  From a language user point of view, it's filenames for Aldor but 
functions
 > in C.

Not really. In Aldor, the name of the file is the name of an implicit 
function in C. I was using this as an example of other languages which 
have naming problems (at different level from the user's perspective).

 >
 > But coming back to your question, yes (at least for ELF files) you 
can use
 > both foos from within one file.
 >
 > Assume I have liba.a and libb.b. Both libraries contain an object file
 > exporting a symbol "foo", referring to "void foo(void) { something; 
}". I
 > want to write demo.c which can use both "foo"s. I suppose there are 
easier
 > ways, but at least the following works:
 >
 > All that's required is a C-file (I'll call it libbwrapper.c) that 
contains
 > something like
 > void foo_from_libb( void )
 > {
 >    foo();
 > }
 >
 > Compile this file and link against libb.a. Afterwards localize the 
symbol
 > "foo" withit the ELF file (e.g.: by objcopy)

Ok, that is not part of C. That is a different tool to manipulate object 
files (in binutils). You can use the same tool for Aldor, after you 
generate the C files.

I'm still not convinced that this would work. Even if I copy the object 
for the second foo in libbwrapper, when I link the executable it will 
still pick one (first?) symbol that matches (unless you really change 
the machine code to jump at the address of the right foo). Can you 
choose from C which foo you want to pick at link time?

 >
 > Then you can write your demo.c using foo for liba's foo and 
foo_from_libb
 > for libb's foo after linking demo.c with both liba and libbwrapper.o.
 >
 > But for Aldor you do not get easy access to all the C files used during
 > compilation,...

You get access to C files if you select them as a target. You can even 
get the C files for library files from the .al file. Then you can do you 
magic in C or assembly to jump to the right address.

So, I guess this would qualify as a solution to Ralf's problem, but I'm 
not going to say it is better than asking the closed source company to 
fix the compatibility issue.

Cheers,
--
Laurentiu