* Undefined reference to glib_E
@ 2007-03-26 10:35 Alexander Camek
2007-03-26 13:14 ` Stefan Bellon
0 siblings, 1 reply; 5+ messages in thread
From: Alexander Camek @ 2007-03-26 10:35 UTC (permalink / raw)
Hi all,
currently I am porting a linux application to windows.
Under Linux all compiles fine, but during compilation or better linking I
get always a undefined reference to glib_E under windows.
I use the gpl version dated to 2006 in order to compile the project with
commandline argument: gnatmake -Pimages.gpr
The project file looks like this:
-- -*- mode: Ada;-*-
with "common";
with "framework";
project images is
for Library_Name use "images";
for Library_Dir use "lib";
for Object_Dir use "obj";
for Library_Kind use "dynamic";
for Source_Dirs use (".", "bind");
for Languages use ("Ada", "C");
for Library_Interface use
("base_images", "generic_images", "images");
package Linker renames Common.Linker;
package Compiler renames Common.Compiler;
package Builder renames Common.Builder;
package Ide renames Common.Ide;
end images;
When I do a static linking, everything works fine, but the dynamic linkage
has this undefined reference.
The Ada_Project_Path, Ada_Include_Path and Ada_Objects_Path is set to point
to the .a files of GtkAda and the GtkAda\bin path is set before the Gnat\bin
path in the enviroment PATH.
Also other project files using Gtkada are compiling correct, but they only
use "for Languages use ("Ada")".
The common project contains the gtkada project.
Did I forget to set some switch? Or have i set something wrong?
What I am confused about is that in the user manual of gnat it is set:
"F.10 Building DLLs with GNAT Project files
There is nothing specific to Windows in this area"
Thanks for any information you can give me in order to point me to the right
direction.
Greetings
Alexander
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Undefined reference to glib_E
2007-03-26 10:35 Undefined reference to glib_E Alexander Camek
@ 2007-03-26 13:14 ` Stefan Bellon
2007-03-26 13:43 ` Alexander Camek
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Bellon @ 2007-03-26 13:14 UTC (permalink / raw)
To: Alexander Camek
Alexander Camek wrote:
> with "common";
> with "framework";
>
> project images is
> for Library_Name use "images";
> for Library_Dir use "lib";
> for Object_Dir use "obj";
> for Library_Kind use "dynamic";
> for Source_Dirs use (".", "bind");
> for Languages use ("Ada", "C");
> for Library_Interface use
> ("base_images", "generic_images", "images");
>
> package Linker renames Common.Linker;
> package Compiler renames Common.Compiler;
> package Builder renames Common.Builder;
> package Ide renames Common.Ide;
>
> end images;
>
> When I do a static linking, everything works fine, but the dynamic
> linkage has this undefined reference.
You are building a DLL on Windows here. A DLL cannot (unlike a
shared object on UNIX) have unresolved symbols. In the worst case you
need an import library. But in this case, there's another way.
> The common project contains the gtkada project.
Somewhere in your GtkAda project file there should be the Linker
package and the Linker_Options defined. Those are necessary when
building a DLL on Windows. In our project files it looks like this:
with "gtkada";
-- ...
project My_Lib is
for Library_Name use "My_Lib";
for Library_Kind use "dynamic";
-- ...
case Common.OS is
when "UNIX" =>
null;
when "Windows_NT" =>
-- On Windows, we need to use GtkAda's Linker_Options to
-- link DLLs depending upon GtkAda.
for Library_Options use GtkAda.Linker'Linker_Options;
end case;
-- ...
end My_Lib
I hope, this helps.
Greetings,
Stefan
--
Stefan Bellon
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Undefined reference to glib_E
2007-03-26 13:14 ` Stefan Bellon
@ 2007-03-26 13:43 ` Alexander Camek
2007-03-26 13:57 ` Stefan Bellon
0 siblings, 1 reply; 5+ messages in thread
From: Alexander Camek @ 2007-03-26 13:43 UTC (permalink / raw)
"Stefan Bellon" <sbellon@sbellon.de> schrieb im Newsbeitrag
news:20070326151427.296f7b0e@cube.tz.axivion.com...
> Alexander Camek wrote:
>
>> with "common";
>> with "framework";
>>
>> project images is
>> for Library_Name use "images";
>> for Library_Dir use "lib";
>> for Object_Dir use "obj";
>> for Library_Kind use "dynamic";
>> for Source_Dirs use (".", "bind");
>> for Languages use ("Ada", "C");
>> for Library_Interface use
>> ("base_images", "generic_images", "images");
>>
>> package Linker renames Common.Linker;
>> package Compiler renames Common.Compiler;
>> package Builder renames Common.Builder;
>> package Ide renames Common.Ide;
>>
>> end images;
>>
>> When I do a static linking, everything works fine, but the dynamic
>> linkage has this undefined reference.
>
> You are building a DLL on Windows here. A DLL cannot (unlike a
> shared object on UNIX) have unresolved symbols. In the worst case you
> need an import library. But in this case, there's another way.
Okay, after some searching i found in the executable i build before the
symbol :(.
So it seems i have to use an import library, because it seems that the build
will not work like under unix.
I first build under unix my "executable" and then use many shared objects.
Do I need in that case the previous named "import library", because windows
is doing the whole a little bit diffrent?
Thanks for the help
Greetings
Alexander
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Undefined reference to glib_E
2007-03-26 13:43 ` Alexander Camek
@ 2007-03-26 13:57 ` Stefan Bellon
2007-03-26 14:45 ` Alexander Camek
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Bellon @ 2007-03-26 13:57 UTC (permalink / raw)
Alexander Camek wrote:
> Okay, after some searching i found in the executable i build before
> the symbol :(.
Sorry, I do not understand what you mean.
> So it seems i have to use an import library, because it seems that
> the build will not work like under unix.
> I first build under unix my "executable" and then use many shared
> objects.
If you build DLLs, then those DLLs need to see all symbols they refer
to. If they depend on other DLLs, that's usually no problem ...
> Do I need in that case the previous named "import library", because
> windows is doing the whole a little bit diffrent?
... but when your DLL indeed depends on the main executable, then you
need an import library. We have such a case as well. In the Linker
section of the main executable we have:
package Linker is
case Common.Target_OS is
when "linux-gnu" =>
for Default_Switches ("ada") use
Common.Linker'Default_Switches ("ada") &
"-Wl,--export-dynamic";
when "solaris2.8" | "solaris2.9" | "solaris2.10" =>
for Default_Switches ("ada") use
Common.Linker'Default_Switches ("ada");
when "mingw32" | "cygwin" =>
for Default_Switches ("ada") use
Common.Linker'Default_Switches ("ada") &
"-Wl,--export-all-symbols,--out-implib,main.lib";
end case;
end Linker;
On GNU/Linux you need the --export-dynamic if you need to get at the
symbols of the main executable from plugins you load via dlopen. On
Solaris this is default. On Windows, you can see the commands that
generate the import library.
Then, in the library that depends on the symbols of the main
executable, we have the following in the project file:
case Common.OS is
when "UNIX" =>
null;
when "Windows_NT" =>
for Library_Options
use GtkAda.Linker'Linker_Options &
(Common.Global_Obj & "main.lib");
end case;
The Common.Global_Obj is the object directory of your main project as
the import library has been placed there.
I hope this helps.
Greetings,
Stefan
--
Stefan Bellon
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Undefined reference to glib_E
2007-03-26 13:57 ` Stefan Bellon
@ 2007-03-26 14:45 ` Alexander Camek
0 siblings, 0 replies; 5+ messages in thread
From: Alexander Camek @ 2007-03-26 14:45 UTC (permalink / raw)
"Stefan Bellon" <sbellon@sbellon.de> schrieb im Newsbeitrag
news:20070326155702.6c20c0b4@cube.tz.axivion.com...
> Alexander Camek wrote:
>> So it seems i have to use an import library, because it seems that
>> the build will not work like under unix.
>> I first build under unix my "executable" and then use many shared
>> objects.
>
> If you build DLLs, then those DLLs need to see all symbols they refer
> to. If they depend on other DLLs, that's usually no problem ...
>
>> Do I need in that case the previous named "import library", because
>> windows is doing the whole a little bit diffrent?
>
> ... but when your DLL indeed depends on the main executable, then you
> need an import library. We have such a case as well. In the Linker
> section of the main executable we have:
>
> package Linker is
> case Common.Target_OS is
> when "linux-gnu" =>
> for Default_Switches ("ada") use
> Common.Linker'Default_Switches ("ada") &
> "-Wl,--export-dynamic";
> when "solaris2.8" | "solaris2.9" | "solaris2.10" =>
> for Default_Switches ("ada") use
> Common.Linker'Default_Switches ("ada");
> when "mingw32" | "cygwin" =>
> for Default_Switches ("ada") use
> Common.Linker'Default_Switches ("ada") &
> "-Wl,--export-all-symbols,--out-implib,main.lib";
> end case;
> end Linker;
>
> On GNU/Linux you need the --export-dynamic if you need to get at the
> symbols of the main executable from plugins you load via dlopen. On
> Solaris this is default. On Windows, you can see the commands that
> generate the import library.
>
> Then, in the library that depends on the symbols of the main
> executable, we have the following in the project file:
>
> case Common.OS is
> when "UNIX" =>
> null;
> when "Windows_NT" =>
> for Library_Options
> use GtkAda.Linker'Linker_Options &
> (Common.Global_Obj & "main.lib");
> end case;
>
> The Common.Global_Obj is the object directory of your main project as
> the import library has been placed there.
>
> I hope this helps.
Yes, this was my problem. Thanks for your help. Now I can build the whole.
Greetings
Alexander
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-03-26 14:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-26 10:35 Undefined reference to glib_E Alexander Camek
2007-03-26 13:14 ` Stefan Bellon
2007-03-26 13:43 ` Alexander Camek
2007-03-26 13:57 ` Stefan Bellon
2007-03-26 14:45 ` Alexander Camek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox