Issue information

Issue ID
#8421
Status
Confirmed
Severity
None
Started
MuriloStrike
Nov 2, 2014 11:48
Last Post
4144
Nov 8, 2014 17:08
Confirmation
N/A

MuriloStrike - Nov 2, 2014 11:48

Hello guys, I decided to start the server in Ubuntu, since I use this OS in my day-to-day, I've done every step in the wiki that has already installed all the necessary software to configure did the following open terminal and navigated to the folder Hercules, open the file configure with "./configure" command, wiped the make with "make clean" and then gave a "make sql," but when I run this command I get the following error:

"/usr/lib/gcc/i686-linux-gnu/4.9/../../../i386-linux-gnu/crt1.o: na função `_start':
/build/buildd/glibc-2.19/csu/../sysdeps/i386/start.S:111: referência indefinida para `main'
collect2: error: ld returned 1 exit status
Makefile:89: recipe for target '../../login-server' failed
make[1]: *** [../../login-server] Error 1
make[1]: Leaving directory '/home/murilo/Hercules/src/login'
Makefile:96: recipe for target 'login_sql' failed
make: *** [login_sql] Error 2"

Print the following error attached.

[sharedmedia=core:attachments:2070]

Haru - Nov 2, 2014 19:02

I see some lto-related errors in your screenshot. Could you show what's before?
Also, what version of Ubuntu are you running? From what I see, lto is failing to link the main() function.
A possible workaround until I can test your version of Ubuntu and fix the issue, would be to pass the --disable-lto option to ./configure (but that's a workaround -- the configure script is supposed to be able to detect a nonfunctional linker)

MuriloStrike - Nov 2, 2014 23:09

I understand, well, I'm using the version of Ubuntu 14.10, ScreenShots the whole process below

[sharedmedia=core:attachments:2086]
[attachment=2087:make_sql.jpg]

4144 - Nov 3, 2014 23:35

I can say what this can happend with gcc 4.9 only.
here on amd64 box same issue.

Haru - Nov 4, 2014 0:49

Could you post your config.log? (The file is automatically generated when you run ./configure)

4144 - Nov 4, 2014 8:24

Haru look like i found way to fix it.
Issue in common lib.
Need replace ar to gcc-ar. Look like in configure possible create check for this. But not sure how test ar here.

gcc-ar is special wrapper over ar.

This is issue look like in gcc 4.9 and current binutils.

Dastgir - Nov 4, 2014 13:24

Yup, seems problem with gcc 4.9(I am using gcc-4.9.1 for test)[code=:0] /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 0 has invalid symbol index 11 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 1 has invalid symbol index 12 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 4 has invalid symbol index 11 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 5 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 6 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 7 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 8 has invalid symbol index 12 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 9 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 10 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 11 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 12 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 13 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 14 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 15 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 16 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 17 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 18 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_info): relocation 19 has invalid symbol index 21 /usr/bin/ld: /usr/lib/debug/usr/lib/x86_64-linux-gnu/crt1.o(.debug_line): relocation 0 has invalid symbol index 2 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status make[1]: *** [../../login-server] Error 1 make[1]: Leaving directory `/root/Hercules/src/login' make: *** [login_sql] Error 2 [/code]
^ Error when make
Config.log: [url="http://upaste.me/c23a157371dc14529"]http://upaste.me/c23a157371dc14529[/url]

MuriloStrike - Nov 4, 2014 14:19

Here my Config.log [url="http://upaste.me/a76715740675401ee"]http://upaste.me/a76715740675401ee[/url]

I using gcc 4.9.1 too

Haru - Nov 5, 2014 2:06

I did some research on the issue. My results are (pretty much in line with 4144 reports):

- GCC 4.9 enables the -fno-fat-lto-objects flag automatically when lto is enabled (see [1] below for info on lto and the fat lto objects, and why this is in theory a good thing.)
- The ar tool (we use it to make the .a files in the src/common directory) needs to be aware of lto in order to be able to work with slim lto objects (or otherwise it'll remove all the functions, since they appear to be unused.)
- There are a few ways to make the ar tool aware of lto and load the proper plugins. In a perfect world, ar would do this automatically.
- We aren't in a perfect world, and as such, the reliable way to get ar to use the appropriate lto plugins is to use the gcc-ar wrapper.
- The above line only applies to gcc of course. People that use llvm/clang, should probably not use gcc-ar.
- It would seem [2] that a way to check for slim lto is to check (in a ./configure test) for the symbol __gnu_lto_slim. This is only on gcc of course.
- Perhaps we could use the above to override AR, setting it to gcc-ar. What if the user has multiple gcc versions installed (or is using a non-system gcc? On my setup, for instance, gcc is gcc-4.9 and gcc-ar is gcc-ar-4.9. If we were to forcefully override AR, setups like this would break)
- Perhaps we could do the above only if we notice that there are slim lto objects *and* the linker fails to link against an archived library with the default (or user-defined) ar tool. (i.e. the configure script could try and detect the presence of __gnu_lto_slim, then try and build/archive a dummy static library, and then link against it to see if it was properly archived, or if the symbols are missing)


[1]: [url="https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html#LTO-Overview"]https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html#LTO-Overview[/url]
[2]: [url="https://sourceware.org/bugzilla/show_bug.cgi?id=13227"]https://sourceware.org/bugzilla/show_bug.cgi?id=13227[/url]

MuriloStrike - Nov 5, 2014 19:37

Haru, what can I do now?

Haru - Nov 6, 2014 21:54

I can't seem to be able to get it to work, even with gcc-ar.

MuriloStrike: until this is fixed, you should be able to get it to compile by running ./configure --disable-lto (it'll disable the link-time optimizations, so your Hercules may be slightly bigger and possibly a bit slower, but it should work at least)

MuriloStrike - Nov 7, 2014 13:40

good, compiles! But I have a doubt, if I compile so the server will slow down processing? or stay the same? and the use of memoria ram change anything? because here only the map-server is consuming 85MB of memory.

Haru - Nov 7, 2014 16:05

It won't use the optimizations that lto offers (this includes file size of the generated executable, performance speed-ups, etc - you can read what lto is [url="http://en.wikipedia.org/wiki/Interprocedural_optimization"]here[/url]). The slowdowns aren't necessarily noticeable though. It's just not as optimized as it would be with lto enabled.

There should be absolutely no differences in memory usage. 85 MB is a reasonable amount of memory for a map-server right now (with no users or few users online). On my machine, a freshly started map-server process (default configuration, compiled in pre-re mode, without lto, and with debug flags enabled) uses 84.1MB. If I disable lto, memory usage stays 84.1MB. (it goes down to 80.9MB if I don't enable the debug symbols)

MuriloStrike - Nov 7, 2014 22:42

Thank you Haru! Helped me a lot!!!!

But when you resolve this issue, please warn here?

This post has been edited by MuriloStrike on Nov 7, 2014 22:47

4144 - Nov 8, 2014 17:08

Haru, if you want test gcc-ar, try build with lto, it fails. then in common/Makefile change ar to gcc-ar.
and try build again. now it should be fine.