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

[Christian Aistleitner]

Hello Laurentiu,

On Thu, 29 Nov 2007 16:10:23 +0100, Laurentiu Dragan <ldragan at aldor.org>  
wrote:

> Christian Aistleitner wrote:
>  >
>  > 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.

And that seems to be a good choice. Aldor is the only language I know  
where such problems exist.


>  > 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.

If they'd choose to use a language that requires it, they would, because  
they'd have to. But I doubt they'd like it.
When using Aldor, I am forced to prefix filenames. I hate it.


> Some companies writing software in Java put their code in packages (they  
> know that this is a way avoid name conflicts).

This is again something completely different.
When coding in Java, the packages are realized by using directories. And  
these directories are reflected in the library (.jar) files.
In java you can have the two source files with the same name and  
everything works nicely--by putting them in different packages. Just  
because of the packages, directories and directory aware libraries, it  
works out.
Aldor does not provide such concepts.

> My solution was a workaround the current implementation of libraries in  
> Aldor.

When I give you a library, and someone else gives you a different library,  
and both libraries contain a file with the same name, you have to have the  
freedom to modify the source code to use them both simultaneously.

Suppose we both do give you the source code, but do not give you our  
allowance to modify the code.

> In Aldor, the name of the file is the name of an implicit function in C.

That's the point. This implicit function causes troubles.

>  > But coming back to your question, yes (at least for ELF files) you  
> can use
>  > both foos from within one file.
>
> 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 would not know how. Can you send a demo?

> I'm still not convinced that this would work.

See the attached file. Unpack and "make". Then execute the demo executable.

liba.c is the source of the first library
libb.c is the source of the first library
Each of these two libraries export a symbol foo.

libbwrapper.c wraps libb to make libb's foo visible under a second name

demo.c is the file calling the two different foos.


> 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.

Can you provide a demo?

> 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.

Some companies shipping non-free (free as in freedom) software are not  
really too concered with bugs. Take Aldor.org for example. Some bugs I  
filed over three years ago still haven't been fixed ;)

Kind regards,
Christian