Jump to content

error installing apollon


aze
 Share

Recommended Posts

Hi folks!

 

I'm having problem to install apollon 0.8.7

 

[root@192 apollon-0.8.7]# make
make  all-recursive
make[1]: Entering directory `/mnt/win_e/apollon-0.8.7'
Making all in apollon
make[2]: Entering directory `/mnt/win_e/apollon-0.8.7/apollon'
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/lib/qt3//include -I/usr/X11R6/include   -DQT_THREAD_SUPPORT  -D_REENTRANT -g -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common  -MT preferences.o -MD -MP -MF ".deps/preferences.Tpo" \
 -c -o preferences.o `test -f 'preferences.cpp' || echo './'`preferences.cpp; \
then mv ".deps/preferences.Tpo" ".deps/preferences.Po"; \
else rm -f ".deps/preferences.Tpo"; exit 1; \
fi
In file included from preferences.cpp:33:
preferences.ui.h:23:29: libgift/libgift.h: No such file or directory
preferences.ui.h:24:26: libgift/conf.h: No such file or directory
In file included from preferences.cpp:33:
preferences.ui.h: In member function `virtual void ApollonPreferencesDialog::readValues()':
preferences.ui.h:81: error: `Config' undeclared (first use this function)
preferences.ui.h:81: error: (Each undeclared identifier is reported only once for each function it appears in.)
preferences.ui.h:81: error: `configuration' undeclared (first use this function)
preferences.ui.h:81: error: `config_new_ex' undeclared (first use this function)
preferences.ui.h:83: error: `config_get_int' undeclared (first use this function)
preferences.ui.h:85: error: `config_get_str' undeclared (first use this function)
preferences.ui.h:90: warning: unused variable `PluginListItem*newItem'
preferences.ui.h:145: error: `config_free' undeclared (first use this function)
preferences.ui.h:152: error: `openFTConfig' undeclared (first use this function)
In file included from preferences.cpp:33:
preferences.ui.h: In member function `virtual void ApollonPreferencesDialog::saveValues()':
preferences.ui.h:303: error: `config_new_ex' undeclared (first use this function)
preferences.ui.h:306: error: `config_set_int' undeclared (first use this function)
preferences.ui.h:319: error: `config_set_str' undeclared (first use this function)
preferences.ui.h:368: error: `config_write' undeclared (first use this function)
preferences.ui.h:371: error: `config_free' undeclared (first use this function)
In file included from preferences.cpp:33:
preferences.ui.h: In member function `virtual void ApollonPreferencesDialog::sltNewPlugin()':
preferences.ui.h:395: warning: unused variable `PluginListItem*newIt'
make[2]: *** [preferences.o] Error 1
make[2]: Leaving directory `/mnt/win_e/apollon-0.8.7/apollon'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/win_e/apollon-0.8.7'
make: *** [all] Error 2

 

Thanks for any help

Link to comment
Share on other sites

find the first error

libgift/libgift.h: No such file or directory
then do;

urpmf libgift.h

to find out what pkg libgift.h is in and install it, Then try again.

 

the second error should be resolved because libgift/conf.h is from the same pkg, or should be.

 

urpmf is your friend :thumbs:

Link to comment
Share on other sites

if you want to build apollon you'll have to have libgift-devel installed.

But you might as well just add a plf source to your urpmi sources and install the rpm. Believe me it works, and it works well! i'm use the gift and fasttrack plugins i got from plf too. its great. ah well to add plf sources check out the FAQ's http://www.mandrakeusers.org/index.php?showtopic=4551

 

enjoy!

Link to comment
Share on other sites

boy....ya'll are alot of help :unsure: :P

 

I was trying to show aze and anyone else that may read this thread how to resovle compile issues themselves w/o having to go to a forum and have someone just tell them.

 

yep,

libgift/libgift.h: No such file or directory
means the libgift devel pkg/s is missing (devel because that's what we're doing involved with a *.h). That's what urpmf will say :wall: Edited by bvc
Link to comment
Share on other sites

urpmf libgift.h

 

nothing was returned

I tried google libgift but I couldn't install it.

where should I go to get packages dependencies when some pack is asked?

 

gift-devel-0.11.4-3plf.i586.rpm

Some package requested cannot be installed:

gift-devel-0.11.4-3plf.i586 (due to unsatisfied gift[== 0.11.4])

do you agree ?

 

 

 

thanks

Edited by aze
Link to comment
Share on other sites

boy....ya'll are alot of help :unsure: :P

 

libgift/libgift.h: No such file or directory
means the libgift devel pkg/s is missing (devel because that's what we're doing involved with a *.h). That's what urpmf will say :wall:

bah we all said the same thing. anyone who compiles enough will learn those errors. my problem is that why would people packaging mandrake rpms want to go through all the work of splitting off lib and include files .... especially on such a small little package as gift. (yes i understand it make some packages smaller but uis it not annoying ahving to go seek a stupid package when it should have been included in the first place?)

 

aze .... it believe tht you will obviously have to install the gift package first then the devel package then you should finally be ready to go.

Link to comment
Share on other sites

aze .... it believe tht you will obviously have to install the gift package first then the devel package then you should finally be ready to go.

yeah I agree with you. but where I will find that?

 

this is the boring part of linux.. linux should have all that dependencies on install cds :furious3:

Link to comment
Share on other sites

bah, we did not all say the same thing. I showed how, illogic-al showed an easier way to get the pkgs, and you stated which pkg. Big diff. Who cares that they're split. What does that have to do with anything? Where ever you find one you'll find the other....You're on a rpm-based distro board....you know that's how it is, should be, and needs to be......deal with it, this is not a source-distro board......and actually the keywords here are 'anyone who compiles enough'. Sure after they've come to a forum and asked after errors in 5 different app compiles they may start to get the idea (some sooner, some later of course).

 

aze, the reason it's not on the cd's is because it's not. It's not a popular app that uses giFT. KDEGift was the main in the past. If every app was on the cd's you'd need 15 cd's, have to pay a lot more for the distro, and the 6 month release cycle would be 12 months.

 

...and yes, plf has.....

[root@suse /]# urpmf --description apollon

apollon:Apollon used to be KdeGiFT, which was based on Kadeau. Now it is an

advanced giFT client with many options.

libapollon0:Shared libraries for apollon.

libapollon0-devel:Header files and static library for development with apollon.

[root@suse /]#urpmf --description gift

gift:This packages containt the giFT daemon. giFT is the filesharing tool for

linux.

lib64gift0:Shared libraries for gift.

lib64gift0-devel:Header files and static library for development with gift.

gift:This packages containt the giFT daemon. giFT is the filesharing tool for

linux.

libgift0:Shared libraries for gift.

libgift0-devel:Header files and static library for development with gift.

gift:This packages containt the giFT daemon. giFT is the filesharing tool for

linux.

libgift0:Shared libraries for gift.

gift-fasttrack:This is the FastTrack plugin for giFT.

gift-openft:This is the OpenFT plugin.

libgift0-devel:Header files and static library for development with gift.

[root@suse /]# urpmf libgift.h

lib64gift0-devel:/usr/include/libgift/libgift.h

libgiFT0-devel:/usr/include/giFT/libgift.h

libgift0-devel:/usr/include/libgift/libgift.h

libgiFT0-devel:/usr/include/giFT/libgift.h

libgiFT0-devel:/usr/include/giFT/libgift.h

libgift0-devel:/usr/include/libgift/libgift.h

libgiFT0-devel:/usr/include/giFT/libgift.h

[root@suse /]#

Link to comment
Share on other sites

actually no it does not "need to be" or "should be" that way. i for one do not run a source based distro and definitely do not want to run one as they do not validate all the time that goes into it. the distro i do run, however, packages source in the manner it is distributed....that is with the "devel" parts included. the learning process is hindered greatly when people assume that their distro has supplied all that a user needs to compile their own source. in fact few of the distros that split up their source packages even bother to mention to the user the they may need to install foo-devel package.

 

sure these distros often have a "developer" set of packages that can be installed at install time but the average user that installs mdk will often pass on that package set because they say to themselves.."i am not a developer"... so right then and there they are making a mistake.

 

so then they are learning their system and find out about such and such and app but, being unfamiliar with the packaging system and package management options, they do not know all of the places to look. they come to a forum like this and ask and someone who is season may just go " if you cannot find it why not just compile it/" they then proceed to answer the inevitable question of how to compile.

 

now thinking they have all the wares to compile they go ahead and start only to find they need this that and the other package. it becomes a huge burden even with package managers that can solve dependencies etc.

 

now as a user of a distro that does not separate out the "devel" components i know how much smoother things can be and how much easier it is to manage the system. i am sure our dial up customers appreciate the fact that once they have their system installed and set up they know they can compile source right away without seeking more and more packages. if they should need to install a package foir what they are trying to build then it is one instll and that is that.

 

for developers it would be alot easier too. i can just imagine what it is like for debian developers or rpm packagers to try and include all of the possible core and developer packages in the metadata in order just to solve dependencies for the package manager demands.

 

granted it is handy in situations where you may only need certain headers or lib files to build your source but those situations are actually rare for the standard user that only occasionally compiles from source.

 

all this being said i think the "best answer" is the one that point to the easiest way for the user of a distro to manage packages. in this case the plf sources. why go through the hassle of compiling when a few tweaks of your system can get your package manager grabbing nice premade and easily manages binary packages.

Edited by sarah31
Link to comment
Share on other sites

well said, but I for one would hate for mandrake to do that. I even tar up and mv my kernel sources to a bkup between compiles because I can't stand unnecessary garbage lying around. If I plan not to compile for a while, I've even removed all devel pkgs in many cases forcing it....and no it doesn't break anything.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...