Multiple shared libraries with a single spec

Multiple shared libraries with a single spec

[Lucretia]

Hi,

One of the things I need to know how to achieve is having a single
specification but different bodies, to create a set of similar shared
libraries. As an example, take the implementation of some maths
routines (vector). I can have a version which will work on all machines
i386 and FPU, then more specific versions which use SSE, MMX, etc. All
of these different libs do the same thing, have the same spec, but
different bodies. So I may have a directory structure like this:

vector.ads
i386/vector.adb
i386/libvector.so
sse/vector.adb
sse/libvector.so
mmx/vector.adb
mmx/libvector.so

Now, I could export a bunch of C functions and use dlopen/dlsym, etc.
but this isn't the best way and it doesn't allow you to use your Ada
libs the way you want to. Also it would make the types slow to use if
they had to go through C constructors and interfaces (like you would a
C++ shared library).

I have just created a test program which creates 2 shared libs (in
separate directories with separate makefiles) and then created adalib
and adainclude directories in which the lib, ali and ads files were
linked to. I then built the test app which linked to the files in
adalib and adainclude. I could then use a symlink to change the library
used. This works, but I'm not too sure if it's the correct way to do
this.

Has anyone else done this sort of thing with GNAT?

Thanks,
Luke.

Re: Multiple shared libraries with a single spec

[Niklas Holsti]

Lucretia wrote:
> Hi,
> 
> One of the things I need to know how to achieve is having a single
> specification but different bodies, to create a set of similar shared
> libraries. As an example, take the implementation of some maths
> routines (vector). I can have a version which will work on all machines
> i386 and FPU, then more specific versions which use SSE, MMX, etc. All
> of these different libs do the same thing, have the same spec, but
> different bodies. So I may have a directory structure like this:
> 
> vector.ads
> i386/vector.adb
> i386/libvector.so
> sse/vector.adb
> sse/libvector.so
> mmx/vector.adb
> mmx/libvector.so
> 
> <snip>
> 
> I have just created a test program which creates 2 shared libs (in
> separate directories with separate makefiles) and then created adalib
> and adainclude directories in which the lib, ali and ads files were
> linked to. I then built the test app which linked to the files in
> adalib and adainclude. I could then use a symlink to change the library
> used. This works, but I'm not too sure if it's the correct way to do
> this.
> 
> Has anyone else done this sort of thing with GNAT?

I'm working on an Ada program that has different versions, as in 
your example. I put the different versions of the package bodies 
(and specifications, too, for some packages) in different 
source-code directories, as you do. To build a specific version of 
the program, I list the source-code directories for the desired 
version in ADA_INCLUDE_PATH (and also in ADA_OBJECTS_PATH, but I 
think this is unnecessary for me) and then run "gnatmake" in a 
directory dedicated to this version. The .ali and .o files and the 
executable go in this version-specific directory. I don't use 
symlinks, just ADA_INCLUDE_PATH.

Mine is a simple and crude approach (it recompiles everything 
separately for each version of the program instead of sharing the 
compilation of shared libraries) but it works well enough for me. 
The library code changes so rarely that its recompilation time is 
irrelevant.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Multiple shared libraries with a single spec

[Lucretia]

Niklas Holsti wrote:
> I'm working on an Ada program that has different versions, as in
> your example. I put the different versions of the package bodies
> (and specifications, too, for some packages) in different
> source-code directories, as you do. To build a specific version of
> the program, I list the source-code directories for the desired
> version in ADA_INCLUDE_PATH (and also in ADA_OBJECTS_PATH, but I
> think this is unnecessary for me) and then run "gnatmake" in a
> directory dedicated to this version. The .ali and .o files and the
> executable go in this version-specific directory. I don't use
> symlinks, just ADA_INCLUDE_PATH.

The problem i've found is, if the .adb file is in the same directory as
the .ali, .o and the shared lib, the source code will be linked
directly into the final executable. The executable still requires the
shared lib, but it doesn't actually use it. How do you get around this?
Do you dump the ali and shared lib to a different directory?

Thanks,
Luke.

Re: Multiple shared libraries with a single spec

[Lucretia]

Actually, could you upload your makefile for one of your libs?

Thanks,
Luke.

Re: Multiple shared libraries with a single spec

[Niklas Holsti]

Lucretia wrote:
> Niklas Holsti wrote:
> 
>>I'm working on an Ada program that has different versions, as in
>>your example. I put the different versions of the package bodies
>>(and specifications, too, for some packages) in different
>>source-code directories, as you do. To build a specific version of
>>the program, I list the source-code directories for the desired
>>version in ADA_INCLUDE_PATH (and also in ADA_OBJECTS_PATH, but I
>>think this is unnecessary for me) and then run "gnatmake" in a
>>directory dedicated to this version. The .ali and .o files and the
>>executable go in this version-specific directory. I don't use
>>symlinks, just ADA_INCLUDE_PATH.
> 
> 
> The problem i've found is, if the .adb file is in the same directory as
> the .ali, .o and the shared lib, the source code will be linked
> directly into the final executable. The executable still requires the
> shared lib, but it doesn't actually use it. How do you get around this?

Ah - when you say "shared lib", do you mean a *dynamically* linked 
library? I thought you just meant a library that is used by 
several programs or different versions of a program, but has 
different implementations for different environments.

Sorry for my misunderstanding. I don't have any experience with 
making dynamically linked libraries.

In my case, the choice of versions influences many parts of the 
program, not just the libraries but also their client packages, so 
linking the libraries dynamically would not make sense.

> Do you dump the ali and shared lib to a different directory?

It may not be relevant to your problem, as I misunderstood your 
aims, but for this program I never have the .adb in the same 
directory as the .ali and .o.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Multiple shared libraries with a single spec

[Stephen Leake]

"Lucretia" <lucretia9@lycos.co.uk> writes:

> One of the things I need to know how to achieve is having a single
> specification but different bodies, to create a set of similar shared
> libraries. 

Excellent idea.

> So I may have a directory structure like this:
>
> vector.ads
> i386/vector.adb
> i386/libvector.so
> sse/vector.adb
> sse/libvector.so
> mmx/vector.adb
> mmx/libvector.so

Locating the object files with the source files is in general a bad
idea, but not relevant to this discussion.

> Now, I could export a bunch of C functions and use dlopen/dlsym, etc.
> but this isn't the best way and it doesn't allow you to use your Ada
> libs the way you want to. Also it would make the types slow to use if
> they had to go through C constructors and interfaces (like you would a
> C++ shared library).

C doesn't have 'constructors', so I don't know what you mean here.

If you want the main program to choose which library implementation to
use at run time, then dynamic library linking is the only option. This
would make sense for a program that could take advantage of different
flavors of x86, as you describe above.

> I have just created a test program which creates 2 shared libs (in
> separate directories with separate makefiles) and then created adalib
> and adainclude directories in which the lib, ali and ads files were
> linked to. I then built the test app which linked to the files in
> adalib and adainclude. I could then use a symlink to change the library
> used. This works, but I'm not too sure if it's the correct way to do
> this.

It's one valid way, and has the advantage of being compiler
independent. But it isn't operating system independent; you can't do
this on Windows.

> Has anyone else done this sort of thing with GNAT?

I use GNAT project files for this; one project file per target. The
Source_Dirs value specifies what Ada bodies to use, by specifying the
directory search path. All objects are placed in one build directory;
one build directory per target.

-- 
-- Stephe

Re: Multiple shared libraries with a single spec

[Lucretia]

Niklas Holsti wrote:
> Ah - when you say "shared lib", do you mean a *dynamically* linked
> library? I thought you just meant a library that is used by
> several programs or different versions of a program, but has
> different implementations for different environments.

Nope a shared library, as in dynamically linked. Hence the use of
dlopen and dlsym in the OP ;-D

> Sorry for my misunderstanding. I don't have any experience with
> making dynamically linked libraries.

No problems. It took a while to get sorted, but it can be done,
although GNAT really makes it difficult.

> In my case, the choice of versions influences many parts of the
> program, not just the libraries but also their client packages, so
> linking the libraries dynamically would not make sense.
>
> > Do you dump the ali and shared lib to a different directory?
>
> It may not be relevant to your problem, as I misunderstood your
> aims, but for this program I never have the .adb in the same
> directory as the .ali and .o.

Ok. I currently build in the directory with the source, I should change
this so that the objects and ali's go somewhere else.

Luke.

Re: Multiple shared libraries with a single spec

[Lucretia]

Stephen Leake wrote:

> Excellent idea.

Yup, just makes this sort of stuff easier to develop.

> Locating the object files with the source files is in general a bad
> idea, but not relevant to this discussion.

See previous post.

> > Now, I could export a bunch of C functions and use dlopen/dlsym, etc.
> > but this isn't the best way and it doesn't allow you to use your Ada
> > libs the way you want to. Also it would make the types slow to use if
> > they had to go through C constructors and interfaces (like you would a
> > C++ shared library).
>
> C doesn't have 'constructors', so I don't know what you mean here.

No, it doesn't but when you create a C++ class library, the easiest way
to do this is to export a C constructor function, e.g.

extern "C" My_Funky_Class *My_DLL_New(void);
extern "C" void My_DLL_Delete(My_Funky_Class *Ptr);

This is what I don't want as any function that uses the maths routines,
basically everything, will end up being really slow as each vector
object will be a "pointer to" and every reference will have to be
dereferenced. This is bad for speed in 3D apps.

> If you want the main program to choose which library implementation to
> use at run time, then dynamic library linking is the only option. This
> would make sense for a program that could take advantage of different
> flavors of x86, as you describe above.
>
> > I have just created a test program which creates 2 shared libs (in
> > separate directories with separate makefiles) and then created adalib
> > and adainclude directories in which the lib, ali and ads files were
> > linked to. I then built the test app which linked to the files in
> > adalib and adainclude. I could then use a symlink to change the library
> > used. This works, but I'm not too sure if it's the correct way to do
> > this.
>
> It's one valid way, and has the advantage of being compiler
> independent. But it isn't operating system independent; you can't do
> this on Windows.

This isn't compiler independent as the library generated won't be able
to be used from another Ada compiler, i.e. the name mangling may not be
the same.

But you should be able to do this on Windows, as I have created 2 types
of C++ class DLL in the past, 1 which uses the C constructor mechanism
described above (i.e. the COM interface type) and another where the C++
class can be linked to directly without using the interface mechanism.

> > Has anyone else done this sort of thing with GNAT?
>
> I use GNAT project files for this; one project file per target. The
> Source_Dirs value specifies what Ada bodies to use, by specifying the
> directory search path. All objects are placed in one build directory;
> one build directory per target.

Hmmm, haven't used project files yet.

I ask about this, because I'm generating 2 libs, each have slightly
different ALI's and I was wondering whether this way would cause
problems in the future?

Thanks,
Luke.

Re: Multiple shared libraries with a single spec

[Pascal Obry]

Lucretia,

> No problems. It took a while to get sorted, but it can be done,
> although GNAT really makes it difficult.

Because you did not read the documentation and certainly not the part
about Library Project support :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Multiple shared libraries with a single spec

[Martin Krischik]

Am 04.11.2005, 15:22 Uhr, schrieb Niklas Holsti <nobody@nowhere.fi>:

> Ah - when you say "shared lib", do you mean a *dynamically* linked  
> library?

"shared lib": Unix World
"dynamically linked": Windows World

two words - same meaning.

Interesting side note: both use "static library" for the oposide.

Martin

Re: Multiple shared libraries with a single spec

[Martin Krischik]

Am 04.11.2005, 17:53 Uhr, schrieb Lucretia <lucretia9@lycos.co.uk>:

> Hmmm, haven't used project files yet.

You shoud, they are very powerfull. Have a look:

http://cvs.sourceforge.net/viewcvs.py/booch95/booch95/GNAT/booch_95.gpr?view=markup

> I ask about this, because I'm generating 2 libs, each have slightly
> different ALI's and I was wondering whether this way would cause
> problems in the future?


Not if you seperate them properly. Project files with options can help  
here.

Martin

Re: Multiple shared libraries with a single spec

[Martin Krischik]

Am 04.11.2005, 17:43 Uhr, schrieb Lucretia <lucretia9@lycos.co.uk>:

> No problems. It took a while to get sorted, but it can be done,
> although GNAT really makes it difficult.

Not true any more! The new GNAT Versions support libs n project files and  
ist very easy indeed.

Martin

Re: Multiple shared libraries with a single spec

[Niklas Holsti]

Martin Krischik wrote:
> Am 04.11.2005, 15:22 Uhr, schrieb Niklas Holsti <nobody@nowhere.fi>:
> 
>> Ah - when you say "shared lib", do you mean a *dynamically* linked  
>> library?
> 
> 
> "shared lib": Unix World
> "dynamically linked": Windows World
> 
> two words - same meaning.

Well, on the other hand the Debian Linux "man" page for "dladdr" 
etc has the title "programming interface to dynamic linking 
loader", so it seems that the Unix word also uses "dynamically 
linked" in some cases. The term also occurs frequently in the 
"man" page for "ld". Perhaps the best Unix usage is to speak of 
"dynamic linking to a shared library" ?

But this is off-topic, sorry...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Multiple shared libraries with a single spec

[Stephen Leake]

"Lucretia" <lucretia9@lycos.co.uk> writes:

> Stephen Leake wrote:
>
>> > I have just created a test program which creates 2 shared libs (in
>> > separate directories with separate makefiles) and then created adalib
>> > and adainclude directories in which the lib, ali and ads files were
>> > linked to. I then built the test app which linked to the files in
>> > adalib and adainclude. I could then use a symlink to change the library
>> > used. This works, but I'm not too sure if it's the correct way to do
>> > this.
>>
>> It's one valid way, and has the advantage of being compiler
>> independent. But it isn't operating system independent; you can't do
>> this on Windows.
>
> This isn't compiler independent as the library generated won't be able
> to be used from another Ada compiler, i.e. the name mangling may not be
> the same.

What I meant was 'using file system symbolic links' is compiler
independent. My option of using GNAT project files is not compiler
independent. 

Hmm. Maybe I misread what you wrote, and you didn't mean 'file system
symbolic links'.

> But you should be able to do this on Windows, 

Windows does not support file system symbolic links.

>> > Has anyone else done this sort of thing with GNAT?
>>
>> I use GNAT project files for this; one project file per target. The
>> Source_Dirs value specifies what Ada bodies to use, by specifying the
>> directory search path. All objects are placed in one build directory;
>> one build directory per target.
>
> Hmmm, haven't used project files yet.

They are very nice. For example, they make it easy to specify compiler
options on a per-file basis (which I use to work around compiler bugs
:). 

> I ask about this, because I'm generating 2 libs, each have slightly
> different ALI's and I was wondering whether this way would cause
> problems in the future?

Of course it can cause problems. But using per-target build
directories, and using project files, can solve those problems.

-- 
-- Stephe

Re: Multiple shared libraries with a single spec

[Lucretia]

Stephen Leake wrote:
> What I meant was 'using file system symbolic links' is compiler
> independent. My option of using GNAT project files is not compiler
> independent.

Oh. Well, the symbolic links are only in use to get the thing working,
nothing more.

> Hmm. Maybe I misread what you wrote, and you didn't mean 'file system
> symbolic links'.
>
> > But you should be able to do this on Windows,
>
> Windows does not support file system symbolic links.

Well, yeah. But I'm working on Linux so I'm not too bothered about
getting a test program working on Windows.

> > Hmmm, haven't used project files yet.
>
> They are very nice. For example, they make it easy to specify compiler
> options on a per-file basis (which I use to work around compiler bugs
> :).

I'll look into it. Can they be used for mixed language programming? I'm
using makefiles for wxAda a the moment.

> > I ask about this, because I'm generating 2 libs, each have slightly
> > different ALI's and I was wondering whether this way would cause
> > problems in the future?
>
> Of course it can cause problems. But using per-target build
> directories, and using project files, can solve those problems.

I had another look at the ALI's and the differences were in the numbers
(hash values, I think).

Thanks,
Luke.

Re: Multiple shared libraries with a single spec

[Martin Krischik]

Am 05.11.2005, 12:41 Uhr, schrieb Stephen Leake <stephen_leake@acm.org>:

>> But you should be able to do this on Windows,

> Windows does not support file system symbolic links.

There is a discussion over at slashdot about that and it looks like NTFS  
does indeed support hard and softlink - all that is missing is "ln.exe"  
but you get that with cygwin.

Personly I know that hardlinks work fine - but I am not at home to check  
softlinks as well.

Martin

Re: Multiple shared libraries with a single spec

[Martin Krischik]

Am 05.11.2005, 13:44 Uhr, schrieb Lucretia <lucretia9@lycos.co.uk>:

>> > Hmmm, haven't used project files yet.
>>
>> They are very nice. For example, they make it easy to specify compiler
>> options on a per-file basis (which I use to work around compiler bugs
>> :).
> I'll look into it. Can they be used for mixed language programming? I'm
> using makefiles for wxAda a the moment.

Depends on the language you want to mix ;-). C and C++ work fine - there  
is a tool which will generate the needed makefiles for you. gpr2make - I  
am not at home so I can guess the name only

Martin

Re: Multiple shared libraries with a single spec

[Pascal Obry]

Martin,

> There is a discussion over at slashdot about that and it looks like
> NTFS  does indeed support hard and softlink - all that is missing is
> "ln.exe"  but you get that with cygwin.

Not only that. AFAIK the Win32 API does not support the softlinks. Only
some "tricks" have been done on the Windows Explorer to be able to use
them... So softlinks on Windows are pretty useless to me.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Multiple shared libraries with a single spec

[Stephen Leake]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> Am 05.11.2005, 13:44 Uhr, schrieb Lucretia <lucretia9@lycos.co.uk>:
>
>>> > Hmmm, haven't used project files yet.
>>>
>>> They are very nice. For example, they make it easy to specify compiler
>>> options on a per-file basis (which I use to work around compiler bugs
>>> :).
>> I'll look into it. Can they be used for mixed language programming? I'm
>> using makefiles for wxAda a the moment.
>
> Depends on the language you want to mix ;-). C and C++ work fine -
> there  is a tool which will generate the needed makefiles for you.
> gpr2make - I  am not at home so I can guess the name only

GNAT GPL 2005 provides 'gprmake', which you run instead of gnatmake.
You can then add C (not C++, I think) files (that is, directories
containing *.c files) to your GNAT project files, and gprmake compiles
the C code into a library, then calls gnatmake to build the Ada main,
automatically linking in the C library. Very convenient.

However, 'gprmake' does not appear in the "super secret" GNAT
documentation, so I guess it qualifies as "top secret" :). GPS may use
it transparently; I don't use GPS.

-- 
-- Stephe

Re: Multiple shared libraries with a single spec

[Stefan Bellon]

Stephen Leake wrote:

> GNAT GPL 2005 provides 'gprmake', which you run instead of gnatmake.
> You can then add C (not C++, I think) files

It works for C++ files as well. I think early versions of gprmake
needed the following package Naming specified inside the project file:

   package Naming is
      for Implementation_Suffix ("C++") use ".cpp";
      for Specification_Suffix ("C++") use ".h";
   end Naming;

But apart from that, C++ should work fine as well.

> (that is, directories
> containing *.c files) to your GNAT project files, and gprmake compiles
> the C code into a library, then calls gnatmake to build the Ada main,

You can even have the "main" in a language like C or C++:

   for Languages use ("Ada", "C", "C++");
   for Main_Language use "C++";
   for Main use ("main.cpp");

> automatically linking in the C library. Very convenient.

Yes, I completely agree.

> However, 'gprmake' does not appear in the "super secret" GNAT
> documentation, so I guess it qualifies as "top secret" :). GPS may use
> it transparently; I don't use GPS.

s/top secret/beta/

;-)

-- 
Dipl.-Inf. Stefan Bellon
Bauhaus Software Technologies | TTI GmbH TGZ Softwareanalysen c/o ISTE
Tel.: +49 711 78 16 221       | Universitätsstraße 38
Fax.: +49 711 78 16 380       | 70569 Stuttgart

Re: Multiple shared libraries with a single spec

[Stephen Leake]

Stefan Bellon <bellon@bauhaus-tec.com> writes:

> Stephen Leake wrote:
>
>> GNAT GPL 2005 provides 'gprmake', which you run instead of gnatmake.
>> You can then add C (not C++, I think) files
>
> It works for C++ files as well. I think early versions of gprmake
> needed the following package Naming specified inside the project file:
>
>    package Naming is
>       for Implementation_Suffix ("C++") use ".cpp";
>       for Specification_Suffix ("C++") use ".h";

Please use ".hpp" for headers; then Emacs and other editors can know
what language you are using!

>    
>    end Naming;
>
> But apart from that, C++ should work fine as well.

Ok, good to know.


> You can even have the "main" in a language like C or C++:
>
>    for Languages use ("Ada", "C", "C++");
>    for Main_Language use "C++";
>    for Main use ("main.cpp");

Ok. I see "Main_Language" is in the GNAT Reference Manual, although it
does not give the list of supported languages (SmallTalk? :).
I guess it's time I sat down and read the whole thing again :).

>> automatically linking in the C library. Very convenient.
>
> Yes, I completely agree.
>
>> However, 'gprmake' does not appear in the "super secret" GNAT
>> documentation, so I guess it qualifies as "top secret" :). GPS may use
>> it transparently; I don't use GPS.
>
> s/top secret/beta/
>
> ;-)

No, it's not "beta"; it's included in the supported release.

-- 
-- Stephe

Re: Multiple shared libraries with a single spec

[Stefan Bellon]

Stephen Leake wrote:
> Stefan Bellon <bellon@bauhaus-tec.com> writes:

[gprmake]

> > s/top secret/beta/
> >
> > ;-)
> 
> No, it's not "beta"; it's included in the supported release.

Then AdaCore seems to disagree with you (I quote): "gprmake is still in
beta". At least it was on 19th September.

-- 
Dipl.-Inf. Stefan Bellon
Bauhaus Software Technologies | TTI GmbH TGZ Softwareanalysen c/o ISTE
Tel.: +49 711 78 16 221       | Universitätsstraße 38
Fax.: +49 711 78 16 380       | 70569 Stuttgart

Re: Multiple shared libraries with a single spec

[Frank J. Lhota]

Pascal Obry wrote:
> Not only that. AFAIK the Win32 API does not support the softlinks. Only
> some "tricks" have been done on the Windows Explorer to be able to use
> them... So softlinks on Windows are pretty useless to me.
> 
> Pascal.

Windows does support soft links through "junctions". What is more 
problematic is the way Win32 handles hard links, i.e. links created by 
the Win32 API function CreateHardLink. According to MS, changes made to 
the file through one link would not be reflected in the directory 
entries for the other links. See

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/hard_links_and_junctions.asp

Several U.S. Government agencies have mandates for POSIX-compliant 
operating systems. MS made Windows NT and its successors POSIX-compliant 
  so that these OS's would meet these mandates, but they did not go 
beyond meeting the bare minimal requirements for POSIX. As often noted, 
the Windows POSIX functionality is pretty bad. The Cygwin emulation of 
Unix under Windows ignores a lot of the official Win32 POSIX facilities.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: Multiple shared libraries with a single spec

[Lucretia]

Stephen Leake wrote:
> > Depends on the language you want to mix ;-). C and C++ work fine -
> > there  is a tool which will generate the needed makefiles for you.
> > gpr2make - I  am not at home so I can guess the name only

C, C++ and Ada

> GNAT GPL 2005 provides 'gprmake', which you run instead of gnatmake.
> You can then add C (not C++, I think) files (that is, directories
> containing *.c files) to your GNAT project files, and gprmake compiles
> the C code into a library, then calls gnatmake to build the Ada main,
> automatically linking in the C library. Very convenient.

Is it possible to *not* build a library from the C code as my code is a
mixture which is, in it's entirety, built into a single library at the
end, the way it should be, in this case!

Thanks,
Luke.

Re: Multiple shared libraries with a single spec

[Pascal Obry]

Frank,

> Windows does support soft links through "junctions". What is more

Good to hear! But look at the documentation. "junctions" are implemented
through "reparse point" and the restrictions are:

<<
The following restrictions apply to reparse points:

    * Reparse points can be established for a directory, but the
directory must be empty. Otherwise, the NTFS file system fails to
establish the reparse point. In addition, you cannot create directories
or files in a directory that contains a reparse point.
    * Reparse points and extended attributes are mutually exclusive. The
NTFS file system cannot create a reparse point when the file contains
extended attributes, and it cannot create extended attributes on a file
that contains a reparse point.
    * Reparse point data, including the tag and optional GUID, cannot
exceed 16 kilobytes. Setting a reparse point fails if the amount of data
to be placed in the reparse point exceeds this limit.
>>

So I think I was right, Windows does not support soft links ;)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Multiple shared libraries with a single spec

[Stephen Leake]

"Lucretia" <lucretia9@lycos.co.uk> writes:

> Stephen Leake wrote:
>> GNAT GPL 2005 provides 'gprmake', which you run instead of gnatmake.
>> You can then add C (not C++, I think) files (that is, directories
>> containing *.c files) to your GNAT project files, and gprmake compiles
>> the C code into a library, then calls gnatmake to build the Ada main,
>> automatically linking in the C library. Very convenient.
>
> Is it possible to *not* build a library from the C code as my code is a
> mixture which is, in it's entirety, built into a single library at the
> end, the way it should be, in this case!

I don't know. You'll have to ask AdaCore, or try reading the gprmake source.

-- 
-- Stephe

Re: Multiple shared libraries with a single spec

[Stefan Bellon]

Lucretia wrote:

> Is it possible to *not* build a library from the C code as my code is
> a mixture which is, in it's entirety, built into a single library at
> the end, the way it should be, in this case!

Libraries which do not contain any Ada files are not supported at
present. However, when you have a mixture of Ada and C, there's no
problem building such a library.

   for Languages use ("Ada", "C");

and an accordingly set Source_Dirs is everything you need in a library
project.

-- 
Dipl.-Inf. Stefan Bellon
Bauhaus Software Technologies | TTI GmbH TGZ Softwareanalysen c/o ISTE
Tel.: +49 711 78 16 221       | Universitätsstraße 38
Fax.: +49 711 78 16 380       | 70569 Stuttgart