Dougiedee13 / gnome2-globalmenu

Automatically exported from code.google.com/p/gnome2-globalmenu
GNU General Public License v2.0
0 stars 0 forks source link

wont compile with giftwrap #543

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. install giftwrap from launchpad ppa.
2. Try to make a deb with gnome2-globalmenu

What is the expected output?
A deb is produced

What do you see instead?
A TON of errors.

What version of the Global Menu are you using? On what operating system?
0.7.8

Original issue reported on code.google.com by coldReac...@gmail.com on 13 Nov 2009 at 2:11

Attachments:

GoogleCodeExporter commented 8 years ago
Ubuntu 9.10 amd64

Original comment by coldReac...@gmail.com on 13 Nov 2009 at 2:11

GoogleCodeExporter commented 8 years ago
underlinking .v.s. overlinking issue.

Is giftwrap the standard way of making ubuntu packages?

Original comment by rainwood...@gmail.com on 9 Dec 2009 at 9:28

GoogleCodeExporter commented 8 years ago
If you ask me: Yes, since it's the most user-friendly way to do so. In fact, I 
do not
know how to do so otherwise.

Original comment by coldReac...@gmail.com on 10 Dec 2009 at 1:57

GoogleCodeExporter commented 8 years ago
same issue with version 0.7.10 && gentoo

http://www.gentoo.org/proj/en/qa/asneeded.xml :
Failure in final linking, undefined symbols

This is the most common error that happens while using --as-needed. It happens 
during the final linking stage of an executable (libraries don't create 
problems, because they are allowed to have undefined symbols). The executable 
linking stage dies because of an undefined symbol that is present in one of the 
libraries fed to the command line. However, the library is not used by the 
executable itself, thus it gets removed by --as-needed.

This usually means that a library was not linked to another library, but was 
using it, and then relying on the final executable to link them together. This 
behavior is also an extra encumbrance on developers using that library because 
they have to check for the requirements.

The fix to this kind of problem is usually simple: just find which library 
provides the symbols and which one is requiring them (the error message from 
the linker should contain the name of the latter). Then make sure that when the 
library is linked from the source files it's also linked to the first. While 
using autotools, the dependent library has to be checked in the configure (this 
should already be the case to specify the dependencies in the pkg-config data 
file or in the script provided) and then the variable carrying this value 
should be added to the LIBADD variable for the library to be built.

Failure in execution, undefined symbols

Sometimes the undefined symbol errors don't happen while linking, but rather at 
the execution of an application built with --as-needed. The cause, however, is 
just the same as for the undefined symbols in linking: a directly-linked 
library did not link one of its dependencies. It also has the same solution: 
find which library carries the undefined symbols and make sure that it gets 
linked to the library providing them. 

Original comment by t.rozbit...@gmail.com on 11 Jan 2011 at 12:23

Attachments: