Re: GTK+ library access issue?
Earnie wrote: However, IMNSHO, if LD can find the references in out-of-order .o object files it should be able to do the same with out-of-order library archives of object files but then I don't code LD. The linker on MacOSX apparently can -- according to the man pages, the traditional restrictions on ordering of -l options don't apply to it. But on most systems, static libraries are scanned once when encountered on the command line, and a .o file is only pulled in if it defines a symbol that is referenced by the currently active set of .o files. Once the relevant set of .o files has been found, all the references between them are then fixed up. Dynamic libraries may be different, since they're treated as a single unit rather than a collection of .o files. -- Greg ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Il giorno lun, 24/10/2011 alle 17.59 -0700, David Buchan ha scritto:
> Interesting. I just tried compiling a simple non-gtk c program:
>
>
> #include
> #include
> #include
>
> int
> main()
> {
> int i;
> double a =3.14;
> double c;
>
> c = log(a);
>
> c = pow(a, i);
>
> }
>
>
>
>
> $ gcc -lm test.c
> /tmp/cc9RccRJ.o: In function `main':
> test.c:(.text+0x1b): undefined reference to `log'
> test.c:(.text+0x33): undefined reference to `pow'
> collect2: ld returned 1 exit status
Try "gcc test.c -lm": I found the object order is important on recent
Ubuntu. Not sure is gcc or ubuntu related.
With autotools I had to move the libs flags in LDADD instead of LDFLAGS.
Ciao.
--
Nicola
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Hi Earnie, On Tue, 25 Oct 2011 09:08:14 -0400 you wrote: > However, IMNSHO, if LD can find the references in out-of-order .o object > files it should be able to do the same with out-of-order library > archives of object files but then I don't code LD. Well, no, for fairly obvious reasons. LD simply doesn't "find the references" in .o object files like it does with libraries. All .o files passed to LD are linked in full, because that's what the user is explicitly telling it to do (and traditionally a .o file only contained ONE chunk of linkable object, so it's fundamentally all-or-nothing). A library is different - it's a collection of .o chunks, and traditionally an ordered one at that. What LD does with a library is to examine each chunk in turn, look to see if it resolves any of the outstanding undefined symbols, and links it in if and only if it does. So there is never a retrospective "go back and examine the libraries to see if we need any other bits" operation. Items are always linked in the order they appear in the command. This also means that it actually matters quite a lot what order you construct your library in! HTH, Rob ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
David Buchan wrote: > Hi Nicola, > > I did find this on the GNU gcc page: "-l libraryIt makes a difference > where in the command you write this option; the linker searches and > processes libraries and object files in the order they are specified. > Thus, `foo.o -lz bar.o' searches library `z' after file foo.obut > before bar.o. If bar.orefers to functions in `z', those functions > may not be loaded." > > http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html > > Seems to confirm it. Interesting. I guess the previous gcc was a bit > more forgiving for my sloppy ways. Yes, that should be true. For ELF objects as used in Linux and more current versions of HP-UX though it doesn't matter where on the command line the shared libraries fall. However, for Windows pe-coff it does matter and the linker would complain about the missing symbols in bar.o. Earnie ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
On Tue, Oct 25, 2011 at 04:22:16PM +0200, Stefano Facchini wrote: > > > Maybe you can find this link interesting ;-) > https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition Oh, great. Another distro forcing --as-needed in a one-size-fits-all manner. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Il giorno mar, 25/10/2011 alle 07.10 -0700, David Buchan ha scritto:
> Hi Nicola,
>
> I did find this on the GNU gcc page:
> "-l library
> It makes a difference where in the command you write this option; the
> linker searches and processes libraries and object files in the order
> they are specified. Thus, `foo.o -lz bar.o' searches library `z' after
> file foo.o but before bar.o. If bar.o refers to functions in `z',
> those functions may not be loaded."
>
> http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
>
> Seems to confirm it. Interesting.
> I guess the previous gcc was a bit more forgiving for my sloppy ways.
>
Maybe you can find this link interesting ;-)
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
The changes it describes have been implemented only in Oneiric
> Dave
>
>
> __
> From: Nicola Fontana
> To: David Buchan
> Cc: David Nečas ; "gtk-list@gnome.org"
>
> Sent: Tuesday, October 25, 2011 8:06 AM
> Subject: Re: GTK+ library access issue?
>
> Il giorno lun, 24/10/2011 alle 17.59 -0700, David Buchan ha scritto:
> > Interesting. I just tried compiling a simple non-gtk c program:
> >
> >
> > #include
> > #include
> > #include
> >
> > int
> > main()
> > {
> > int i;
> > double a =3.14;
> > double c;
> >
> > c = log(a);
> >
> > c = pow(a, i);
> >
> > }
> >
> >
> >
> >
> > $ gcc -lm test.c
> > /tmp/cc9RccRJ.o: In function `main':
> > test.c:(.text+0x1b): undefined reference to `log'
> > test.c:(.text+0x33): undefined reference to `pow'
> > collect2: ld returned 1 exit status
>
> Try "gcc test.c -lm": I found the object order is important on recent
> Ubuntu. Not sure is gcc or ubuntu related.
>
> With autotools I had to move the libs flags in LDADD instead of
> LDFLAGS.
>
> Ciao.
> --
> Nicola
>
>
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Hi Nicola,
I did find this on the GNU gcc page:
"-l libraryIt makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order they
are specified. Thus, `foo.o -lz bar.o' searches library `z'
after file foo.obut before bar.o. If bar.orefers
to functions in `z', those functions may not be loaded."
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
Seems to confirm it. Interesting.
I guess the previous gcc was a bit more forgiving for my sloppy ways.
Dave
From: Nicola Fontana
To: David Buchan
Cc: David Nečas ; "gtk-list@gnome.org"
Sent: Tuesday, October 25, 2011 8:06 AM
Subject: Re: GTK+ library access issue?
Il giorno lun, 24/10/2011 alle 17.59 -0700, David Buchan ha scritto:
> Interesting. I just tried compiling a simple non-gtk c program:
>
>
> #include
> #include
> #include
>
> int
> main()
> {
> int i;
> double a =3.14;
> double c;
>
> c = log(a);
>
> c = pow(a, i);
>
> }
>
>
>
>
> $ gcc -lm test.c
> /tmp/cc9RccRJ.o: In function `main':
> test.c:(.text+0x1b): undefined reference to `log'
> test.c:(.text+0x33): undefined reference to `pow'
> collect2: ld returned 1 exit status
Try "gcc test.c -lm": I found the object order is important on recent
Ubuntu. Not sure is gcc or ubuntu related.
With autotools I had to move the libs flags in LDADD instead of LDFLAGS.
Ciao.
--
Nicola___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Greg Ewing wrote: > Paul Davis wrote: > >> the gnu linker follows a unix tradition of interpreting the list >> of explicitly and implictly provided object files names as a >> dependency order. consider two files, a.o and b.o. suppose that a.o >> uses a function or symbol found only in b.o. in general, the linker >> will be able to link these two if the order given is "a.o b.o" but >> not if its "b.o a.o". > > Are you sure about that? I thought that ordering was only important > for libraries, and then only insofar as it affects which .o files get > pulled out of the library. > > But the order of -l options can certainly be important in any case. > I can confirm what Greg is saying. I made the same fallacy just last week on the mingw-users list as was bluntly made a fool; I tested it. However, IMNSHO, if LD can find the references in out-of-order .o object files it should be able to do the same with out-of-order library archives of object files but then I don't code LD. Earnie ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Paul Davis wrote: the gnu linker follows a unix tradition of interpreting the list of explicitly and implictly provided object files names as a dependency order. consider two files, a.o and b.o. suppose that a.o uses a function or symbol found only in b.o. in general, the linker will be able to link these two if the order given is "a.o b.o" but not if its "b.o a.o". Are you sure about that? I thought that ordering was only important for libraries, and then only insofar as it affects which .o files get pulled out of the library. But the order of -l options can certainly be important in any case. -- Greg ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Thanks to everybody for the great support! I really appreciate it. Dave From: Paul Davis To: David Buchan Cc: gtk-list list Sent: Monday, October 24, 2011 10:54 PM Subject: Re: GTK+ library access issue? On Mon, Oct 24, 2011 at 10:17 PM, David Buchan wrote: > ok. So, I did a complete reinstall of Ubuntu (it's relatively quick, so why > not?). > This did nothing. Smae old story. > > I then got back on the net and tried Paul's suggestion: > "Try putting it [-lm] at the end of the command, just for kicks." > i.e., > > gcc test.c -lm > > Not only did that work for test.c, but it also solved my gtk problem! > I'm gobsmacked. > How come that works, but putting the lib flags before the filename(s) > doesn't? the gnu linker follows a unix tradition of interpreting the list of explicitly and implictly provided object files names as a dependency order. consider two files, a.o and b.o. suppose that a.o uses a function or symbol found only in b.o. in general, the linker will be able to link these two if the order given is "a.o b.o" but not if its "b.o a.o". there are exceptions to this even with the gnu linker, and certainly with non-gnu linkers. but in general when you construct a link command (such as "gcc -lm text.c") you need to think a bit about ordering things so that when A has a dependency on B, A appears before B. this applies whether its an explicit reference to an object file (like "a.o") or something implicit like -lm or text.c --p___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
On Mon, Oct 24, 2011 at 10:17 PM, David Buchan wrote: > ok. So, I did a complete reinstall of Ubuntu (it's relatively quick, so why > not?). > This did nothing. Smae old story. > > I then got back on the net and tried Paul's suggestion: > "Try putting it [-lm] at the end of the command, just for kicks." > i.e., > > gcc test.c -lm > > Not only did that work for test.c, but it also solved my gtk problem! > I'm gobsmacked. > How come that works, but putting the lib flags before the filename(s) > doesn't? the gnu linker follows a unix tradition of interpreting the list of explicitly and implictly provided object files names as a dependency order. consider two files, a.o and b.o. suppose that a.o uses a function or symbol found only in b.o. in general, the linker will be able to link these two if the order given is "a.o b.o" but not if its "b.o a.o". there are exceptions to this even with the gnu linker, and certainly with non-gnu linkers. but in general when you construct a link command (such as "gcc -lm text.c") you need to think a bit about ordering things so that when A has a dependency on B, A appears before B. this applies whether its an explicit reference to an object file (like "a.o") or something implicit like -lm or text.c --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
ok. So, I did a complete reinstall of Ubuntu (it's relatively quick, so why not?). This did nothing. Smae old story. I then got back on the net and tried Paul's suggestion: "Try putting it [-lm] at the end of the command,just for kicks." i.e., gcc test.c -lm Not only did that work for test.c, but it also solved my gtk problem! I'm gobsmacked. How come that works, but putting the lib flags before the filename(s) doesn't? You blew my (now very grateful) mind. Dave From: David Buchan To: David Nečas Cc: "gtk-list@gnome.org" Sent: Monday, October 24, 2011 7:06 PM Subject: Re: GTK+ library access issue? Hi Dave, Yes, these commands were copy and pasted directly from the Makefile. I wouldn't trust myself to type it correctly. I've been using the same Makefile for about 6 months or more. In fact, the program was compiled a day before I had to replace the hard drive. The only reason I recompiled was to make sure I still could after reinstalling Ubuntu. Oh, how surprised I was. The first batch of errors are: main.c: In function ‘main’: main.c:34:76: warning: variable ‘entry46_text’ set but not used [-Wunused-but-set-variable] main.o: In function `main': /main.c:43: undefined reference to `g_threads_got_initialized' /main.c:44: undefined reference to `g_thread_init' /main.c:46: undefined reference to `gtk_init' /main.c:49: undefined reference to `g_malloc0' /main.c:50: undefined reference to `g_malloc0' /main.c:51: undefined reference to `g_malloc0' /main.c:52: undefined reference to `g_malloc0' /main.c:53: undefined reference to `g_malloc0' /main.c:54: more undefined references to `g_malloc0' follow main.o: In function `main': /main.c:57: undefined reference to `gtk_builder_new' /main.c:58: undefined reference to `gtk_builder_add_from_file' /main.c:59: undefined reference to `g_log' /main.c:60: undefined reference to `g_free' /main.c:65: undefined reference to `g_slice_alloc' /main.c:68: undefined reference to `gtk_widget_get_type' /main.c:68: undefined reference to `gtk_builder_get_object' /main.c:68: undefined reference to `g_type_check_instance_cast' /main.c:69: undefined reference to `gtk_widget_get_type' /main.c:69: undefined reference to `gtk_builder_get_object' /main.c:69: undefined reference to `g_type_check_instance_cast' /main.c:70: undefined reference to `gtk_widget_get_type' /main.c:70: undefined reference to `gtk_builder_get_object' /main.c:70: undefined reference to `g_type_check_instance_cast' /main.c:73: undefined reference to `gtk_toggle_button_get_type' /main.c:73: undefined reference to `gtk_builder_get_object' /main.c:73: undefined reference to `g_type_check_instance_cast' /main.c:74: undefined reference to `gtk_toggle_button_get_type' /main.c:74: undefined reference to `gtk_builder_get_object' /main.c:74: undefined reference to `g_type_check_instance_cast' /main.c:75: undefined reference to `gtk_toggle_button_get_type' /main.c:75: undefined reference to `gtk_builder_get_object' /main.c:75: undefined reference to `g_type_check_instance_cast' /main.c:76: undefined reference to `gtk_toggle_button_get_type' /main.c:76: undefined reference to `gtk_builder_get_object' /main.c:76: undefined reference to `g_type_check_instance_cast' /main.c:77: undefined reference to `gtk_widget_get_type' /main.c:77: undefined reference to `gtk_builder_get_object' /main.c:77: undefined reference to `g_type_check_instance_cast' /main.c:78: undefined reference to `gtk_toggle_button_get_type' /main.c:78: undefined reference to `gtk_builder_get_object' /main.c:78: undefined reference to `g_type_check_instance_cast' /main.c:79: undefined reference to `gtk_widget_get_type' etc... ending with... collect2: ld returned 1 exit status make: *** [x] Error 1 The above is a direct copy and paste EXCEPT that I removed the directory structure preceding '/main.c' on each line, and changed the program name to 'x' in the last line. All in all, there's 1749 lines of this. I painstakingly went through it and except the 1st, rather trivial error, they're all of the same nature. The first error was not picked up with my previous install. I suspect I now have a slightly newer gcc that is more thorough. I do wonder whether the Ubuntu repository has changed content, or maybe I forgot that I originally installed something else. Seems odd though, as things like g_malloc0 and g_free are so fundamental, I would've thought it would be in libgtk2.0-dev. As I said in a previous email, I installed libgtk-3-dev first, got all these errors, then installed libgtk2.0-dev as well. When that didn't work, I tried sudo aptitude remove libgtk-3-dev and tried to compil
Re: GTK+ library access issue?
He did use gcc -lm. It says so in the shell paste. On Mon, Oct 24, 2011 at 8:06 PM, Paul Davis wrote: > 2011/10/24 David Buchan : > > Interesting. I just tried compiling a simple non-gtk c program: > > apparently you didn't use -lm > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
2011/10/24 David Buchan : > Interesting. I just tried compiling a simple non-gtk c program: apparently you didn't use -lm ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Interesting. I just tried compiling a simple non-gtk c program:
#include
#include
#include
int
main()
{
int i;
double a =3.14;
double c;
c = log(a);
c = pow(a, i);
}
$ gcc -lm test.c
/tmp/cc9RccRJ.o: In function `main':
test.c:(.text+0x1b): undefined reference to `log'
test.c:(.text+0x33): undefined reference to `pow'
collect2: ld returned 1 exit status
Now that is weird. Related? Maybe I need to totally reinstall gcc or even
Ubuntu.
Boy I hope this turns out to be something less sinister.
Dave
From: David Buchan
To: David Nečas
Cc: "gtk-list@gnome.org"
Sent: Monday, October 24, 2011 7:06 PM
Subject: Re: GTK+ library access issue?
Hi Dave,
Yes, these commands were copy and pasted directly from the Makefile. I wouldn't
trust myself to type it correctly.
I've been using the same Makefile for about 6 months or more. In fact, the
program was compiled a day before I had to replace the hard drive.
The only reason I recompiled was to make sure I still could after reinstalling
Ubuntu. Oh, how surprised I was.
The first batch of errors are:
main.c: In function ‘main’:
main.c:34:76: warning: variable ‘entry46_text’ set but not used
[-Wunused-but-set-variable]
main.o: In function `main':
/main.c:43: undefined
reference to `g_threads_got_initialized'
/main.c:44: undefined reference to `g_thread_init'
/main.c:46: undefined reference to `gtk_init'
/main.c:49: undefined reference to `g_malloc0'
/main.c:50: undefined reference to `g_malloc0'
/main.c:51: undefined reference to `g_malloc0'
/main.c:52: undefined reference to `g_malloc0'
/main.c:53: undefined reference to `g_malloc0'
/main.c:54: more undefined references to `g_malloc0' follow
main.o: In function `main':
/main.c:57: undefined reference to `gtk_builder_new'
/main.c:58: undefined reference to `gtk_builder_add_from_file'
/main.c:59: undefined reference to `g_log'
/main.c:60: undefined reference to `g_free'
/main.c:65: undefined reference to `g_slice_alloc'
/main.c:68: undefined reference to `gtk_widget_get_type'
/main.c:68: undefined reference to `gtk_builder_get_object'
/main.c:68: undefined reference to `g_type_check_instance_cast'
/main.c:69:
undefined reference to `gtk_widget_get_type'
/main.c:69: undefined reference to `gtk_builder_get_object'
/main.c:69: undefined reference to `g_type_check_instance_cast'
/main.c:70: undefined reference to `gtk_widget_get_type'
/main.c:70: undefined reference to `gtk_builder_get_object'
/main.c:70: undefined reference to `g_type_check_instance_cast'
/main.c:73: undefined reference to `gtk_toggle_button_get_type'
/main.c:73: undefined reference to `gtk_builder_get_object'
/main.c:73: undefined reference to `g_type_check_instance_cast'
/main.c:74: undefined reference to `gtk_toggle_button_get_type'
/main.c:74: undefined reference to `gtk_builder_get_object'
/main.c:74: undefined reference to `g_type_check_instance_cast'
/main.c:75: undefined reference to `gtk_toggle_button_get_type'
/main.c:75: undefined reference to `gtk_builder_get_object'
/main.c:75: undefined reference to
`g_type_check_instance_cast'
/main.c:76: undefined reference to `gtk_toggle_button_get_type'
/main.c:76: undefined reference to `gtk_builder_get_object'
/main.c:76: undefined reference to `g_type_check_instance_cast'
/main.c:77: undefined reference to `gtk_widget_get_type'
/main.c:77: undefined reference to `gtk_builder_get_object'
/main.c:77: undefined reference to `g_type_check_instance_cast'
/main.c:78: undefined reference to `gtk_toggle_button_get_type'
/main.c:78: undefined reference to `gtk_builder_get_object'
/main.c:78: undefined reference to `g_type_check_instance_cast'
/main.c:79: undefined reference to `gtk_widget_get_type'
etc... ending with...
collect2: ld returned 1 exit status
make: *** [x] Error 1
The above is a direct copy and paste EXCEPT that I removed the directory
structure preceding '/main.c' on each line, and changed the program name to 'x'
in the last line.
All in all, there's 1749 lines of this. I painstakingly went through it and
except the 1st, rather trivial error, they're all of the same nature.
The first error was not picked up with my previous install. I suspect I now
have a slightly newer gcc that is more thorough.
I do wonder whether the Ubuntu repository has changed content, or maybe I
forgot that I originally installed something else.
Seems odd though, as things like g_malloc0 and g_free are so fundamental, I
would've thought it would be in libgtk2.0-dev.
As I said in a previous email, I installed libgtk-3-dev first, got all these
errors, then installed libgtk2.0-dev as well.
When that didn't work, I tried
sudo aptitude remove libgtk-3-de
Re: GTK+ library access issue?
Hi Dave, Yes, these commands were copy and pasted directly from the Makefile. I wouldn't trust myself to type it correctly. I've been using the same Makefile for about 6 months or more. In fact, the program was compiled a day before I had to replace the hard drive. The only reason I recompiled was to make sure I still could after reinstalling Ubuntu. Oh, how surprised I was. The first batch of errors are: main.c: In function ‘main’: main.c:34:76: warning: variable ‘entry46_text’ set but not used [-Wunused-but-set-variable] main.o: In function `main': /main.c:43: undefined reference to `g_threads_got_initialized' /main.c:44: undefined reference to `g_thread_init' /main.c:46: undefined reference to `gtk_init' /main.c:49: undefined reference to `g_malloc0' /main.c:50: undefined reference to `g_malloc0' /main.c:51: undefined reference to `g_malloc0' /main.c:52: undefined reference to `g_malloc0' /main.c:53: undefined reference to `g_malloc0' /main.c:54: more undefined references to `g_malloc0' follow main.o: In function `main': /main.c:57: undefined reference to `gtk_builder_new' /main.c:58: undefined reference to `gtk_builder_add_from_file' /main.c:59: undefined reference to `g_log' /main.c:60: undefined reference to `g_free' /main.c:65: undefined reference to `g_slice_alloc' /main.c:68: undefined reference to `gtk_widget_get_type' /main.c:68: undefined reference to `gtk_builder_get_object' /main.c:68: undefined reference to `g_type_check_instance_cast' /main.c:69: undefined reference to `gtk_widget_get_type' /main.c:69: undefined reference to `gtk_builder_get_object' /main.c:69: undefined reference to `g_type_check_instance_cast' /main.c:70: undefined reference to `gtk_widget_get_type' /main.c:70: undefined reference to `gtk_builder_get_object' /main.c:70: undefined reference to `g_type_check_instance_cast' /main.c:73: undefined reference to `gtk_toggle_button_get_type' /main.c:73: undefined reference to `gtk_builder_get_object' /main.c:73: undefined reference to `g_type_check_instance_cast' /main.c:74: undefined reference to `gtk_toggle_button_get_type' /main.c:74: undefined reference to `gtk_builder_get_object' /main.c:74: undefined reference to `g_type_check_instance_cast' /main.c:75: undefined reference to `gtk_toggle_button_get_type' /main.c:75: undefined reference to `gtk_builder_get_object' /main.c:75: undefined reference to `g_type_check_instance_cast' /main.c:76: undefined reference to `gtk_toggle_button_get_type' /main.c:76: undefined reference to `gtk_builder_get_object' /main.c:76: undefined reference to `g_type_check_instance_cast' /main.c:77: undefined reference to `gtk_widget_get_type' /main.c:77: undefined reference to `gtk_builder_get_object' /main.c:77: undefined reference to `g_type_check_instance_cast' /main.c:78: undefined reference to `gtk_toggle_button_get_type' /main.c:78: undefined reference to `gtk_builder_get_object' /main.c:78: undefined reference to `g_type_check_instance_cast' /main.c:79: undefined reference to `gtk_widget_get_type' etc... ending with... collect2: ld returned 1 exit status make: *** [x] Error 1 The above is a direct copy and paste EXCEPT that I removed the directory structure preceding '/main.c' on each line, and changed the program name to 'x' in the last line. All in all, there's 1749 lines of this. I painstakingly went through it and except the 1st, rather trivial error, they're all of the same nature. The first error was not picked up with my previous install. I suspect I now have a slightly newer gcc that is more thorough. I do wonder whether the Ubuntu repository has changed content, or maybe I forgot that I originally installed something else. Seems odd though, as things like g_malloc0 and g_free are so fundamental, I would've thought it would be in libgtk2.0-dev. As I said in a previous email, I installed libgtk-3-dev first, got all these errors, then installed libgtk2.0-dev as well. When that didn't work, I tried sudo aptitude remove libgtk-3-dev and tried to compile with gtk2. When that still did the same thing, I went back an did sudo aptitude install libgtk-3-dev again, figuring that having more libraries increases my chances of success (sign of a desperate man). My (possibly faulty) understanding is that aptitude carefully keeps track of what is installed and all dependencies, so you get nice clean installs and removals. Thanks for taking a look Dave. Dave From: David Nečas To: David Buchan Cc: "gtk-list@gnome.org" Sent: Monday, October 24, 2011 5:46 PM Subject: Re: GTK+ library access issue? On Mon, Oct 24, 2011 at 01:49:05PM -0700, David Buchan wrote: > I tried pkg-config from the command line and h
Re: GTK+ library access issue?
On Mon, Oct 24, 2011 at 01:49:05PM -0700, David Buchan wrote: > I tried pkg-config from the command line and here's what we get: > > $ pkg-config --cflags gtk+-2.0 gmodule-2.0 > -pthread -I/usr/include/gtk-2.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 > -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 > -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng12 > > $ pkg-config --libs gtk+-2.0 gmodule-2.0 > -pthread -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 > -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 > -lfreetype -lfontconfig -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt > -lglib-2.0 This looks good. So, (1) Are these flags actually used in the compilation – check the actual command printed by make. I can see your Makefile variables are called CCFLAGS and LIBS instead of the more usual CFLAGS and LDFLAGS, however, if they are consistently called like this it is not a problem. (2) What are the *first* errors you get after cleaning the source tree and running make? Failing to link is often caused by some previous problems; do you really get only linker errors and no errors from earlier compilation stages? Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
Thanks Dave. I tried pkg-config from the command line and here's what we get: $ pkg-config --cflags gtk+-2.0 gmodule-2.0 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 $ pkg-config --libs gtk+-2.0 gmodule-2.0 -pthread -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 Does anybody see anything missing that would cause such basic things as g_free to be missing? Dave From: David Nečas To: David Buchan Cc: "gtk-list@gnome.org" Sent: Monday, October 24, 2011 11:48 AM Subject: Re: GTK+ library access issue? On Mon, Oct 24, 2011 at 08:09:39AM -0700, David Buchan wrote: > Trying to make now gives over 1700 errors, ALL of which are like this small > sample: > > /x.c:43: undefined reference to `g_threads_got_initialized' > /x.c:44: undefined reference to `g_thread_init' > /x.c:46: undefined reference to `gtk_init' > /x.c:49: undefined reference to `g_malloc0' > /x.c:57: undefined reference to `gtk_builder_new' > /x.c:60: undefined reference to `g_free' > /x.c:98: undefined reference to `gtk_entry_get_type' > etc etc... > collect2: ld returned 1 exit status > make: *** [x] Error 1 A typical symptom of empty CFLAGS and LIBS due to a pkg-config error. Run the pkg-config commands manually and see what they print. Fix the problems (probably something missing). I cannot give any Ubuntu-specific advice but the problem is usually obvious from the pkg-config errors. Yeti___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ library access issue?
On Mon, Oct 24, 2011 at 08:09:39AM -0700, David Buchan wrote: > Trying to make now gives over 1700 errors, ALL of which are like this small > sample: > > /x.c:43: undefined reference to `g_threads_got_initialized' > /x.c:44: undefined reference to `g_thread_init' > /x.c:46: undefined reference to `gtk_init' > /x.c:49: undefined reference to `g_malloc0' > /x.c:57: undefined reference to `gtk_builder_new' > /x.c:60: undefined reference to `g_free' > /x.c:98: undefined reference to `gtk_entry_get_type' > etc etc... > collect2: ld returned 1 exit status > make: *** [x] Error 1 A typical symptom of empty CFLAGS and LIBS due to a pkg-config error. Run the pkg-config commands manually and see what they print. Fix the problems (probably something missing). I cannot give any Ubuntu-specific advice but the problem is usually obvious from the pkg-config errors. Yeti ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GTK+ library access issue?
Hi guys, I think I have a dumb question. I had been maintaining a c/GTK+2 program for the last year. My OS was Ubuntu lucid. This weekend, I replaced the hard drive (I keep my programming projects on a RAID though). I installed the latest Ubuntu (oneiric, I think they call it...not sure). I also installed GTK+3, knowing full well there would be some differences. sudo aptitude install libgtk-3-dev sudo aptitude install glade Since I had previously been using GTK+2, my Makefile used to say: CC = gcc CCFLAGS = `pkg-config --cflags gtk+-2.0 gmodule-2.0` LIBS = `pkg-config --libs gtk+-2.0 gmodule-2.0` DEBUG = -Wall -g but since I installed GTK+3, I changed it to: CC = gcc CCFLAGS = `pkg-config --cflags gtk+-3.0 gmodule-2.0` LIBS = `pkg-config --libs gtk+-3.0 gmodule-2.0` DEBUG = -Wall -g I should say that my program has not been modified in a month or so and should compile with no warnings or errors. Nothing has been changed. Trying to make now gives over 1700 errors, ALL of which are like this small sample: /x.c:43: undefined reference to `g_threads_got_initialized' /x.c:44: undefined reference to `g_thread_init' /x.c:46: undefined reference to `gtk_init' /x.c:49: undefined reference to `g_malloc0' /x.c:57: undefined reference to `gtk_builder_new' /x.c:60: undefined reference to `g_free' /x.c:98: undefined reference to `gtk_entry_get_type' etc etc... collect2: ld returned 1 exit status make: *** [x] Error 1 Fearing GTK+3 was radically different to GTK+2, I reverted my Makefile to the first version given above with GTK+2. I then did: sudo aptitude install libgtk2.0-dev and then typed make. All the same errors appear. To me, this is simply an issue of it not finding the libraries. Have I forgotten to do something when I installed the dev libraries? My instinct tells me I'll groan when I see how dumb I am. Any help is appreciated. Dave___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
