[Bug other/58900] New: parsing bug: undefined reference for libraries, specified before source files

[nick87720z at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900

Bug ID: 58900
   Summary: parsing bug: undefined reference for libraries,
specified before source files
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nick87720z at gmail dot com

Just an example. I have simple hand-written makefile, which builds executable
with one line. These commands will fail:
$ gcc ${common_flags} ${GTK_FLAGS} -o file_loader file_loader.c
file_loader_callbacks.c
$ gcc -o file_loader ${common_flags} ${GTK_FLAGS} file_loader.c
file_loader_callbacks.c

And only this works:
$ gcc -o file_loader file_loader.c file_loader_callbacks.c ${common_flags}
${GTK_FLAGS}

Strongest trick is that it breaks automatic rules from working (when you just
specify standard things like CC,CFLAGS,LDFLAGS and specify targets with
requirements, not specifying exact commands for each target).

Versions.
OS - ubuntu 12.04. Specified version is gcc-4.8 (Ubuntu 4.8.1-2ubuntu1~12.04)
4.8.1. But it also happens with
* gcc-4.6 (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04) 4.6.4
* gcc-4.7 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3 (this i have set default
for now)

[Bug other/58900] parsing bug: undefined reference for libraries, specified before source files

[nick87720z at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900

--- Comment #1 from nick87720z at gmail dot com ---
Posting exact makefile, which leads to this error:

/ Makefile ===\
include_flags = "../misc"
common_flags = -O0 -g3 -ggdb3 -std=gnu99 -I${include_flags}

CFLAGS = ${common_flags} `pkg-config --cflags gtk+-2.0`
LDFLAGS = ${common_flags} `pkg-config --libs gtk+-2.0`

all: file_loader

file_loader: file_loader.c file_loader_callbacks.c
\ Makefile ===/

$ make
cc -O0 -g3 -ggdb3 -std=gnu99 -I `pkg-config --cflags gtk+-2.0`  -O0 -g3 -ggdb3
-std=gnu99 -I `pkg-config --libs gtk+-2.0`  file_loader.c
file_loader_callbacks.c   -o file_loader
/tmp/cchQVCEN.o: In function `setup_menu':
/home/nick87720z/dev/lfhde/file_loader.c:15: undefined reference to
`gtk_menu_shell_get_type'
/home/nick87720z/dev/lfhde/file_loader.c:15: undefined reference to
`gtk_menu_bar_new'
/home/nick87720z/dev/lfhde/file_loader.c:15: undefined reference to
`g_type_check_instance_cast'
everything from
gtk2-related stuff

[Bug other/58900] parsing bug: undefined reference for libraries, specified before source files

[nick87720z at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900

--- Comment #2 from nick87720z at gmail dot com ---
Changing file_loader dependencies to object files doesn't solve problem. After
two successful compilation commands final gcc command, linking executable,
gives same error.

[Bug other/58900] parsing bug: undefined reference for libraries, specified before source files

[nick87720z at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900

--- Comment #3 from nick87720z at gmail dot com ---
Looks like i just did not get something from gcc info book. After short search
for topics about gcc for possible describing of such error i found one
(russian), explicating it by feature to specify some libraries only for some
object/source files, specified for linker (or gcc command with same effect):
http://pyviy.blogspot.ru/2010/12/gcc.html

I got totally >3 topics, dedicated to gcc compilation process, from search (not
google - nigma), but only this describes, what happens in such case.

So, is it make's issue? (GNU Make 3.81)
I'm in a maze.

[Bug other/58900] parsing bug: undefined reference for libraries, specified before source files

[nick87720z at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900

nick87720z at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from nick87720z at gmail dot com ---
Finally found it in info book, in description for -l option. Sorry for wasting
your time.

[Bug c/61469] New: language feature: Support for enum underlying type

[nick87720z at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

Bug ID: 61469
   Summary: language feature: Support for enum underlying type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nick87720z at gmail dot com

Just like some other features (inline functions, const, bool), ability to
specify data type for enumeration should be useful, since enumeration is just a
restriction for possible values.

Unlike C++, where type is specified as "enum class type ...", i propose
following forms:
- enum(type) ...
- type enum ...

[Bug c/61469] language feature: Support for enum underlying type

[nick87720z at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #2 from nick87720z at gmail dot com ---
Didn't know about this form. What i mentioned, i found othere:
http://en.wikipedia.org/wiki/Enumerated_type#C.2B.2B

[Bug c/61469] language feature: Support for enum underlying type

[nick87720z at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469

--- Comment #5 from nick87720z at gmail dot com ---
I remember case, when bigger size, than from int, was needed - it was 64-bit
integer, used as flag container. Program, using it, is not my. When i decided
to reimplement it as enum, author explained me problem.

As for standard, there are still things not in standard - GCC extensions
(such as computed labels, for which i even exactly know possible use case -
some kind of bridges to seemlessly skip certain checks, which are useless after
decision is done all, with one or two exceptions)
and this one, imho, is good candidate for implementation;
personally i don't care very much about other compilers, thus don't fear of
such proposals :].