comp.lang.ada
 help / color / mirror / Atom feed
* 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