* Shared library project @ 2010-06-02 11:05 AndreiK 2010-06-02 11:09 ` AndreiK 0 siblings, 1 reply; 11+ messages in thread From: AndreiK @ 2010-06-02 11:05 UTC (permalink / raw) Hello everybody! Can somebody what does this mean? The compiler outputs: "shared library project "X" cannot import project "Y" that is not a shared library project" used Windows hosted GNAT GPL and GPS 2009 and compiler, just downloaded. Thank you! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-02 11:05 Shared library project AndreiK @ 2010-06-02 11:09 ` AndreiK 2010-06-02 11:46 ` Yannick Duchêne (Hibou57) 2010-06-02 12:02 ` sjw 0 siblings, 2 replies; 11+ messages in thread From: AndreiK @ 2010-06-02 11:09 UTC (permalink / raw) The "X" project file is: =============================== with "../AdFilters/cpp_adfilters.gpr"; project Cpp_BI_SSLL_DLL is for Languages use ("C++"); for Object_Dir use project'Object_Dir & "../../obj"; for Source_Dirs use project'Source_Dirs & "./src"; for Library_Dir use "lib"; for Library_Name use "BISD"; for Library_Kind use "dynamic"; package Naming is for Specification_Suffix ("C++") use ".h"; for Implementation_Suffix ("C++") use ".cpp"; end Naming; end Cpp_BI_SSLL_DLL; =================================== The "Y" project file is: ================================= with "../SystemsCL/cpp_systemscl.gpr"; project Cpp_AdFilters is for Languages use ("C++"); for Object_Dir use project'Object_Dir & "../../obj"; for Source_Dirs use project'Source_Dirs & "./src"; package Naming is for Specification_Suffix ("C") use ".h"; for Implementation_Suffix ("C") use ".c"; for Specification_Suffix ("C++") use ".h"; for Implementation_Suffix ("C++") use ".cpp"; end Naming; end Cpp_AdFilters; =================================== Thanks to everybody for some advise! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-02 11:09 ` AndreiK @ 2010-06-02 11:46 ` Yannick Duchêne (Hibou57) 2010-06-09 11:33 ` AndreiK 2010-06-02 12:02 ` sjw 1 sibling, 1 reply; 11+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-02 11:46 UTC (permalink / raw) Le Wed, 02 Jun 2010 13:05:38 +0200, AndreiK <andrei.krivoshei@gmail.com> a écrit: > Hello everybody! Hello you! > Can somebody what does this mean? > > The compiler outputs: > "shared library project "X" cannot import project "Y" that is not a > shared library project" As the message says, you are attempting, from a library project, to import a project which is not a library project. CPP_AdFilters does not contain any “for Library_Name use ...;” so it is not a library project. As far as I know, a library project can only import library projects. Both must be library project. The page http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Library-Projects.html says “Standard project files can import library project files.” Library project are to be imported from standard project, while standard project are not to be imported from library project. This is just like an application depends on a library, while a library is not to depend on an application. Le Wed, 02 Jun 2010 13:09:24 +0200, AndreiK <andrei.krivoshei@gmail.com> a écrit: > The "X" project file is: > > =============================== > with "../AdFilters/cpp_adfilters.gpr"; > > project Cpp_BI_SSLL_DLL is > > for Languages use ("C++"); > > for Object_Dir use project'Object_Dir & "../../obj"; > for Source_Dirs use project'Source_Dirs & "./src"; > > for Library_Dir use "lib"; > for Library_Name use "BISD"; > for Library_Kind use "dynamic"; > > package Naming is > for Specification_Suffix ("C++") use ".h"; > for Implementation_Suffix ("C++") use ".cpp"; > end Naming; > > end Cpp_BI_SSLL_DLL; > =================================== > > The "Y" project file is: > ================================= > with "../SystemsCL/cpp_systemscl.gpr"; > > project Cpp_AdFilters is > > for Languages use ("C++"); > > for Object_Dir use project'Object_Dir & "../../obj"; > for Source_Dirs use project'Source_Dirs & "./src"; > > package Naming is > for Specification_Suffix ("C") use ".h"; > for Implementation_Suffix ("C") use ".c"; > for Specification_Suffix ("C++") use ".h"; > for Implementation_Suffix ("C++") use ".cpp"; > end Naming; > > end Cpp_AdFilters; > =================================== > > Thanks to everybody for some advise! -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-02 11:46 ` Yannick Duchêne (Hibou57) @ 2010-06-09 11:33 ` AndreiK 2010-06-09 14:24 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 11+ messages in thread From: AndreiK @ 2010-06-09 11:33 UTC (permalink / raw) > > As far as I know, a library project can only import library projects. Both > must be library project. > > The pagehttp://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Library-Projects.html > says > “Standard project files can import library project files.” > There is sayd, that "Standard project files can import library project files", BUT not sayd, that "Standard project files MUST import ONLY library project files" Have somebody any advise? Best regards, Andrei ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-09 11:33 ` AndreiK @ 2010-06-09 14:24 ` Yannick Duchêne (Hibou57) 2010-06-10 5:10 ` AdaMagica 2010-06-10 12:50 ` Andrei Krivoshei 0 siblings, 2 replies; 11+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-09 14:24 UTC (permalink / raw) Le Wed, 09 Jun 2010 13:33:47 +0200, AndreiK <andrei.krivoshei@gmail.com> a écrit: > There is sayd, that "Standard project files can import library project > files", BUT not sayd, that "Standard project files MUST import ONLY > library project files" > Have somebody any advise? > > Best regards, > Andrei Hi Andrei With due respect, your comment seems contradictory with your original post. In your original post, Cpp_BI_SSLL_DLL, which is a library project, attempts (and fails to) import Cpp_AdFilters, which is a standard project, that is, an application project. Either you wanted to import a library project from a standard project, and then what you posted in the original post is wrong (it do the opposite), either you wanted to import a standard project from a standard project as you say in the present post, and then, your original post is wrong two, because is imports a standard project from a library project. What was your original intent please ? Have a nice day -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-09 14:24 ` Yannick Duchêne (Hibou57) @ 2010-06-10 5:10 ` AdaMagica 2010-06-10 12:50 ` Andrei Krivoshei 1 sibling, 0 replies; 11+ messages in thread From: AdaMagica @ 2010-06-10 5:10 UTC (permalink / raw) To summarize the GNAT project import relations: A library project can only import library projects. A normal (a non-library) project can import library projects and other normal projects, i.e. any projects. There are also abstract projects, i.e. those without sources. I guess they can only import other abstract projects, but I haven't the documentation at hand. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-09 14:24 ` Yannick Duchêne (Hibou57) 2010-06-10 5:10 ` AdaMagica @ 2010-06-10 12:50 ` Andrei Krivoshei 2010-06-10 13:04 ` Yannick Duchêne (Hibou57) 2010-06-10 13:48 ` Dmitry A. Kazakov 1 sibling, 2 replies; 11+ messages in thread From: Andrei Krivoshei @ 2010-06-10 12:50 UTC (permalink / raw) > What was your original intent please? My original intent: The dinamic library project, say A project, (the final product) shoould import some another project, say B project, (collection of functions and objects- tagged records and etc). I am myself the author of the both projects, therefore for me doesn't matter what kind of project I select for B. But the final library project must be compiled correctly. Ok, if "A library project can only import library projects.", then why I cannot import the static library project into dynamic library project? If I try do this, the gnatmake gives: [mlcb_fe_dll.gpr:3:09: shared library project "mlcb_fe_dll" cannot import static library project "sp_lib"] Thus, if I want to build the dynamic library project, which uses another projects, then I need to change the type of those projects to 'dynamic', and consequently, the resulting library, A.dll (for the Windows) MUST be supplyed by whole complect of others libraries (B.dll, C.dll, ...), which were imported into project A? With regards, Andrei ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-10 12:50 ` Andrei Krivoshei @ 2010-06-10 13:04 ` Yannick Duchêne (Hibou57) 2010-06-10 19:53 ` Simon Wright 2010-06-10 13:48 ` Dmitry A. Kazakov 1 sibling, 1 reply; 11+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-10 13:04 UTC (permalink / raw) Le Thu, 10 Jun 2010 14:50:17 +0200, Andrei Krivoshei <andrei.krivoshei@gmail.com> a écrit: > My original intent: > > The dinamic library project, say A project, (the final product) > shoould import some another project, say B project, (collection of > functions and objects- tagged records and etc). > I am myself the author of the both projects, therefore for me doesn't > matter what kind of project I select for B. But the final library > project must be compiled correctly. So B has to be a library... which seems OK after what follows. > Ok, if "A library project can only import library projects.", then why > I cannot import the static library project into dynamic library > project? > If I try do this, the gnatmake gives: [mlcb_fe_dll.gpr:3:09: shared > library project "mlcb_fe_dll" cannot import static library project > "sp_lib"] Did you try to make all library dynamic ? Are there some reason which disallows this ? > Thus, if I want to build the dynamic library project, which uses > another projects, then I need to change the type of those projects to > 'dynamic', So you may have a DLL depending on another DLL, which is legal on Windows. > and consequently, the resulting library, A.dll (for the > Windows) MUST be supplyed by whole complect of others libraries > (B.dll, C.dll, ...), which were imported into project A? I am not sure I have understood. If A.dll depends on B.dll and C.dll, this should be OK. Whar kind of dependencies do you have ? Are they like the ones I give ? I am bit surprised, as it should be possible to build a DLL using static library. Unfortunately, I have never experimented this with GNAT. Anyway, feel free to give more details. -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-10 13:04 ` Yannick Duchêne (Hibou57) @ 2010-06-10 19:53 ` Simon Wright 0 siblings, 0 replies; 11+ messages in thread From: Simon Wright @ 2010-06-10 19:53 UTC (permalink / raw) "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes: > I am bit surprised, as it should be possible to build a DLL using > static library. Unfortunately, I have never experimented this with > GNAT. Anyway, feel free to give more details. Like I said above, provided you compile the static library in such a way that it can be used in a dynamic context. With some systems this would mean you had to compile the static library with -fPIC (position-independent code). I expect that what's happening is that - in systems where it's needed - GNAT is supplying this flag automatically for the dynamic library and not for the static library. So on those systems linking the dynamic library against static objects wouldn't work and is disallowed. And in the interests of portability it's disallowed even on systems where there's no need for such a flag. But I don't know. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-10 12:50 ` Andrei Krivoshei 2010-06-10 13:04 ` Yannick Duchêne (Hibou57) @ 2010-06-10 13:48 ` Dmitry A. Kazakov 1 sibling, 0 replies; 11+ messages in thread From: Dmitry A. Kazakov @ 2010-06-10 13:48 UTC (permalink / raw) On Thu, 10 Jun 2010 05:50:17 -0700 (PDT), Andrei Krivoshei wrote: > The dinamic library project, say A project, (the final product) > shoould import some another project, say B project, (collection of > functions and objects- tagged records and etc). > I am myself the author of the both projects, therefore for me doesn't > matter what kind of project I select for B. But the final library > project must be compiled correctly. > > Ok, if "A library project can only import library projects.", then why > I cannot import the static library project into dynamic library > project? That depends on the linker and loader capacities of the given OS. In the worst case you have to distinguish the library build project and the library import project. (These can be physically one gpr file, though) The former can import anything. The latter describes a library which is already linked and can only be loaded, but not re-linked. In this case it may not depend on a static library. > Thus, if I want to build the dynamic library project, which uses > another projects, then I need to change the type of those projects to > 'dynamic', and consequently, the resulting library, A.dll (for the > Windows) MUST be supplyed by whole complect of others libraries > (B.dll, C.dll, ...), which were imported into project A? No, you can build a library as you wish. It can incorporate other projects, i.e. became one big lump, or else refer to other projects in the form of dynamic libraries. The choice is up to you. When your library is to be used by in other projects you describe it appropriately for them (using Externally_Built set to true). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Shared library project 2010-06-02 11:09 ` AndreiK 2010-06-02 11:46 ` Yannick Duchêne (Hibou57) @ 2010-06-02 12:02 ` sjw 1 sibling, 0 replies; 11+ messages in thread From: sjw @ 2010-06-02 12:02 UTC (permalink / raw) On Jun 2, 12:09 pm, AndreiK <andrei.krivos...@gmail.com> wrote: > The "X" project file is: In general, different compiler options (eg -fpic) are needed when compiling a shared library; so your CPP_AdFilters project might use the wrong options. Each project (that actually has source in it) needs to have its own Object_Dir, I think yours may be the same? (I'm not familiar with "project'Object_Dir" used like this, does it mean the current directory? -- yes, nice!) you might consider just exporting variables: in CPP_AdFilters, Source_Dirs := project'Source_Dirs & "./src"; for Source_Dirs use (); in Cpp_BI_SSLL_DLL, for Source_Dirs use project'Source_Dirs & "./src" & CPP_AdFilters.Source_Dirs; (not sure about the bracketing there). ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-06-10 19:53 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-06-02 11:05 Shared library project AndreiK 2010-06-02 11:09 ` AndreiK 2010-06-02 11:46 ` Yannick Duchêne (Hibou57) 2010-06-09 11:33 ` AndreiK 2010-06-09 14:24 ` Yannick Duchêne (Hibou57) 2010-06-10 5:10 ` AdaMagica 2010-06-10 12:50 ` Andrei Krivoshei 2010-06-10 13:04 ` Yannick Duchêne (Hibou57) 2010-06-10 19:53 ` Simon Wright 2010-06-10 13:48 ` Dmitry A. Kazakov 2010-06-02 12:02 ` sjw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox