discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HelpViewer 0.3 : error while linking


From: Patrick Cardona
Subject: Re: HelpViewer 0.3 : error while linking
Date: Sun, 28 Jun 2020 21:19:30 +0200
User-agent: GNUMail (Version 1.3.0)

Hi Riccardo,

-- 
Bien cordialement,
Patrick CARDONA
On 2020-06-28 20:07:46 +0200 Riccardo Mottola <riccardo.mottola@libero.it> 
wrote:

> Hi Patrick,
> 
> 
> On 6/26/20 2:24 PM, Patrick Cardona wrote:
> 
>> I tried today a whole make at the root of the freshly downloaded gap folder 
>> :
> 
>> 1) I am missing some dependencies :
> 
>>    Creating DataBasinKit.framework/Versions/1.1/Resources...
>>    Updating Version/Current symlink...
>> Making all for framework DataBasinKit...
>>    Compiling file DBSoap.m ...
>> In file included from DBSoap.m:28:
>> ./DBSoap.h:27:9: fatal error: 'WebServices/WebServices.h' file not found
>> #import <WebServices/WebServices.h>
> 
>> Are the WebServices a part from WebKit ? I searched form deb libs, but did 
>> not find it.
> 
> 
> No, they are provided with libs-webservices (aka GSWS) and libs-performance.
> 
> However, if you don't have a salesforce.com ORG and login to access, it is a 
> pretty useless app. Although if you do, then it is my "pet project"
> 

So maybe that particular app which is not useful for everyone (I am not a 
member of salesforce.com)
should not be a part of the 'gap' ?

I think a good approach for the beginners should allow a simple make at the 
root of the gap tree  to discover 
the basic apps.
But If some app like Databasin is blocking the whole making process, this root 
GNUmakefile in the top of the gap tree
becomes useless, and somebody guessing how to make the apps might find by hand 
what bundle to make first,
and son on.
Also, like Patryck dit it for the GNUstep core project, it would be very useful 
to supply a script to get first all the relative dependencies.

> 
> 
>> 2) I tried then a single app : Cynthiune, and I got the same error I 
>> already put on the list :
> 
>> Making all in Bundles/ALSA ...
>> Making all for bundle ALSA...
>>    Creating ALSA.output/....
>>    Compiling file ALSA.m ...
>>    Linking bundle ALSA ...
>> /usr/bin/ld.gold : erreur : le symbole __malloc_initialize_hook a une 
>> version GLIBC_2.4 indéfinie
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> make[4]: *** 
>> [/usr/GNUstep/System/Library/Makefiles/Instance/bundle.make:205: 
>> ALSA.output/./ALSA] Error 1
>> make[3]: *** 
>> [/usr/GNUstep/System/Library/Makefiles/Instance/bundle.make:193: 
>> internal-bundle-run-compile-submake] Error 2
>> make[2]: *** [/usr/GNUstep/System/Library/Makefiles/Master/rules.make:297: 
>> ALSA.all.bundle.variables] Error 2
>> make[1]: *** [/usr/GNUstep/System/Library/Makefiles/Master/bundle.make:37: 
>> internal-all] Error 2
>> make: *** 
>> [/usr/GNUstep/System/Library/Makefiles/Master/serial-subdirectories.make:53: 
>> internal-all] Error 2
> 
> 
> Have seen that... I don't know, all this linker stuff is a mess. I did try 
> with gcc and its runtime and it worked some weeks ago. So many variants, 
> sorry.

Well, I wanted to use clang because many advices at the list said it would be 
better to learn Objectice-C and create new apps with that modern compiler.
But I feel that with my RPI 32 bit, and the tests you did, I should revert to 
the 'old' GCC and make it all again,

> 
> (do you have alsa, libasound and it's dev libraries installed? otherwise try 
> some other backend
yes. I did install those ALSA dependencies.

)
> 
> 
> Riccardo
> 
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]