HelpViewer 0.3 : error while linking

[Patrick Cardona]

Hi All,

I am trying to compile HelpViewer (version : 0.3).

First, I had to change some header calls, because GSXML.h vas presumed to be in 'Foundation' while it was in GNUstepBase.
I modified accordingly to the right path TextFormatterXLP.h, line 35
and HandlerStructureXLP.h to set the correct path I guessed :
#include "GNUstepBase/GSXML.h"

But finally, I got an error with the linker :

Linking app HelpViewer ...
mainWindowController.m:0 : erreur : référence à « ASSIGN » non définie
mainWindowController.m:0 : erreur : référence à « RELEASE » non définie
mainWindowController.m:0 : erreur : référence à « RELEASE » non définie
mainWindowController.m:0 : erreur : référence à « RELEASE » non définie
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [/usr/GNUstep/System/Library/Makefiles/Instance/application.make:133: HelpViewer.app/./HelpViewer] Error 1
make[2]: *** [/usr/GNUstep/System/Library/Makefiles/Instance/application.make:147: internal-app-run-compile-submake] Error 2
make[1]: *** [/usr/GNUstep/System/Library/Makefiles/Master/rules.make:297: HelpViewer.all.app.variables] Error 2
make: *** [/usr/GNUstep/System/Library/Makefiles/Master/application.make:38: internal-all] Error 2

Regards,

--
Bien cordialement,
Patrick CARDONA

[Fred Kiefer]

This just means that the file is missing an import for GNUstep.h

[Riccardo Mottola]

Hi Patrick,

where did you got HelpViewer? Where is the actual repository of it?
Maybe the code bitrotted a bit and could be updated. I wonder if is in a
maintained repository or needs to be "adopted" somewhere.

Riccardo

Patrick Cardona via Discussion list for the GNUstep programming

[H. Nikolaus Schaller]

> Am 17.06.2020 um 21:37 schrieb Riccardo Mottola <riccardo...@libero.it>:
>
> Hi Patrick,
>
> where did you got HelpViewer? Where is the actual repository of it?

Interesting. It is not recorded in http://www.gnustep.org/softwareindex/

[H. Nikolaus Schaller]

> Am 17.06.2020 um 22:11 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>
>
>> Am 17.06.2020 um 21:37 schrieb Riccardo Mottola <riccardo...@libero.it>:
>>
>> Hi Patrick,
>>
>> where did you got HelpViewer? Where is the actual repository of it?
>
> Interesting. It is not recorded in http://www.gnustep.org/softwareindex/

I found a source:

http://deb.debian.org/debian/pool/main/h/helpviewer.app/

There is: helpviewer.app_0.3.orig.tar.gz

[Patrick Cardona]

Hi Nikolaus,
Hi all,

--
Bien cordialement,
Patrick CARDONA

On 2020-06-17 22:19:16 +0200 H. Nikolaus Schaller <h...@goldelico.com> wrote:

>
>> Am 17.06.2020 um 22:11 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>
>
>>> Am 17.06.2020 um 21:37 schrieb Riccardo Mottola
>>> <riccardo...@libero.it>:
>
>>> Hi Patrick,
>
>>> where did you got HelpViewer? Where is the actual repository of it?
>
>> Interesting. It is not recorded in http://www.gnustep.org/softwareindex/
>
> I found a source:
>
> http://deb.debian.org/debian/pool/main/h/helpviewer.app/
>
> There is: helpviewer.app_0.3.orig.tar.gz

I got the same version, but the code was downloaded from the site provided by Nicolas Roard :

http://www.roard.com/helpviewer/

Regards,
Patrick

[Riccardo Mottola]

Hi Patrick, hi all,

Patrick Cardona via Discussion list for the GNUstep programming
environment wrote:

>>> Interesting. It is not recorded inhttp://www.gnustep.org/softwareindex/

>> I found a source:
>>
>> http://deb.debian.org/debian/pool/main/h/helpviewer.app/
>>
>> There is: helpviewer.app_0.3.orig.tar.gz
> I got the same version, but the code was downloaded from the site provided by Nicolas Roard :
>
> http://www.roard.com/helpviewer/
>
>

I just wrote Nicolas, I imported HelpViewer into GAP, so it has a public
home.
I will try to fix at least the basic bit rot and then see.

If you have gotten GAP SVN, you will find it in system apps.

I fixed the header import issues and everything compiles for me.

However, the application barely functions for me when I open one of the
examples. Most of the titles are displayed with a blue box, which I bet
is an artifact of some sort.
Many warnings too.... let's see if I can fix them all!

Riccardo

[Yavor Doganov]

Riccardo Mottola wrote:
> However, the application barely functions for me when I open one of
> the examples. Most of the titles are displayed with a blue box, which
> I bet is an artifact of some sort.
> Many warnings too.... let's see if I can fix them all!

Take a look at the Debian patches [1]; most of these issues are
fixed. At least it is able to display its own help and there are no
compilation warnings.

[1] https://sources.debian.org/src/helpviewer.app/0.3-8/debian/patches/

[Patrick Cardona]

Hi Riccardo,
Hi Yavor,

Maybe I did not the things as I should. Please, help me to understand :

1) I made the GNUstep core from the git repository and Clang-7, to
target GNUstep runtime 1.9 because my arm CPU is only 32bit, as I said
in my previous message.

2) Then, I searched around from GAP (github clone of Savannah) and
many other source sites to grab the GNUstep tagged apps and tried to
make them one by one with the make way.
And I did not use deb source packages because I thought they could
not be compatible or they should use the olg GCC to make those.

If I get some package from deb source and I try to rebuild it as the
Debian doc says (1) I am afraid this could make a dependency conflict
with the apps already installed by hand.

Do You think the best way is : I could get the deb source, apply the
patch and make them by hand ?

(1)
https://debian-administration.org/article/20/Rebuilding_Debian_packages

P.S.1 : Yavor, I found the patched source from the Debian repo.
P.S.2 : Riccardo, I was not able to find the source you patched from
the git nor from the SVN. Is there another site I did not find ?
These are the sites where I searched :
http://cvs.savannah.nongnu.org/viewvc/gap/gap/
https://github.com/gnustep/gap
http://www.gnustep.org/softwareindex/

Regards,

--
Bien cordialement,
Patrick CARDONA

[Yavor Doganov]

On Sun, 21 Jun 2020 11:27:27 +0300,

Patrick Cardona via Discussion list for the GNUstep programming environment wrote:

> If I get some package from deb source and I try to rebuild it as the
> Debian doc says (1) I am afraid this could make a dependency conflict
> with the apps already installed by hand.

Just use the .orig.tar.gz from the Debian source package and apply the
patches as you would normally do with a regular tarball/source tree.
No need to build the .deb; it wouldn't work anyway as you're using the
GNUstep runtime.

> Do You think the best way is : I could get the deb source, apply the
> patch and make them by hand ?

Yes, ignore all Debian docs -- they are irrelevant for your use case.

[Patrick Cardona]

Hi Yavor,

Thank you for the answer.
I was able to get the source from Debian repo and got it compiled.

But after the installation, the app cannot be opened : it failed with a segmentation fault after many
warnings about 'incorrect signature'. Here is the output :

pi@raspberrypi:~ $ openapp HelpViewer
2020-06-23 21:45:13.775 HelpViewer[3131:3131] styleoffsets ... guessing offsets
2020-06-23 21:45:13.790 HelpViewer[3131:3131] styleoffsets ... guessing offsets
Calling [NSApplication -hide:] with incorrect signature. Method has v12@0:4@8,
selector has v0@+4:+8@+12
Calling [NSApplication -terminate:] with incorrect signature. Method has v12@0:
4@8, selector has v0@+4:+8@+12
Calling [NSApplication -hide:] with incorrect signature. Method has v12@0:4@8,
selector has v0@+4:+8@+12
Calling [NSApplication -terminate:] with incorrect signature. Method has v12@0:
4@8, selector has v0@+4:+8@+12
Calling [NSApplication -hide:] with incorrect signature. Method has v12@0:4@8,
selector has v0@+4:+8@+12
Calling [NSApplication -terminate:] with incorrect signature. Method has v12@0:
4@8, selector has v0@+4:+8@+12
Calling [NSApplication -hide:] with incorrect signature. Method has v12@0:4@8,
selector has v0@+4:+8@+12
Calling [NSApplication -terminate:] with incorrect signature. Method has v12@0:
4@8, selector has v0@+4:+8@+12
Calling [NSApplication -hide:] with incorrect signature. Method has v12@0:4@8,
selector has v0@+4:+8@+12
Calling [NSApplication -terminate:] with incorrect signature. Method has v12@0:
4@8, selector has v0@+4:+8@+12
Calling [NSApplication -hide:] with incorrect signature. Method has v12@0:4@8,
selector has v0@+4:+8@+12
Calling [NSApplication -terminate:] with incorrect signature. Method has v12@0:
4@8, selector has v0@+4:+8@+12
2020-06-23 21:45:14.699 HelpViewer[3131:3131] Exception occurred while loading m
odel: Codepoint out of range in constant string
2020-06-23 21:45:14.700 HelpViewer[3131:3131] Failed to load Gorm
2020-06-23 21:45:14.700 HelpViewer[3131:3131] Impossible de charger le fichier m
odèle principal 'Main'
Erreur de segmentation


Regards.

--
Bien cordialement,
Patrick CARDONA

[Riccardo Mottola]

Hi,

Yavor Doganov wrote:
> Take a look at the Debian patches [1]; most of these issues are
> fixed. At least it is able to display its own help and there are no
> compilation warnings.
>
> [1]https://sources.debian.org/src/helpviewer.app/0.3-8/debian/patches/

thank you. It's a good starting point - I am reviewing then piece after
piece and reapplying them. I believe some type conversions need to be
different though.

Also, there is a piece I don't understand, but maybe I will after
reviewing it better.


I noticed that on one computer HelpViewer starts and works, as I said,
but on another one it does not even load the Gorm file. I will see if
these patches help, otherwise, some deeper debugging is needed.

Riccardo

[Riccardo Mottola]

Hi Patric,

Patrick Cardona via Discussion list for the GNUstep programming
environment wrote:

> 1) I made the GNUstep core from the git repository and Clang-7, to
> target GNUstep runtime 1.9 because my arm CPU is only 32bit, as I said
> in my previous message.
>
> 2) Then, I searched around from GAP (github clone of Savannah) and
> many other source sites to grab the GNUstep tagged apps and tried to
> make them one by one with the make way.
> And I did not use deb source packages  because I thought they could
> not be compatible or they should use the olg GCC to make those.

GAP stuff builds with GCC fine. I think actually 99% of the apps to not
require the new runtime.
However, build consistently everything with the same compiler, so if you
rebuild core gnustep, then, of course, rebuild everything.
Don't mix.

>
> P.S.1 : Yavor, I found the patched source from the Debian repo.
> P.S.2 : Riccardo, I was not able to find the source you patched from
> the git nor from the SVN. Is there another site I did not find ?
> These are the sites where I searched :
> http://cvs.savannah.nongnu.org/viewvc/gap/gap/

Oh, this is historic! you landed into CVS, the project was migrated to
SVN. We cannot disable CVS for you not to confuse things because the
webpages are on it.

The correct repository is here:
http://svn.savannah.gnu.org/viewvc/gap/trunk/

(and of course, update all your other apps too if you were using them
from GAP and want to try the latest version, the CVS one you got were
years old!)

> https://github.com/gnustep/gap
>
The git mirror is out of date... it was done by Greg, but he never
updated it after the switch from gna.

Riccardo

[Riccardo Mottola]

Hi Patric,


I think the warnings are harmless. I get them on my Laptop, yet it works.
However, on my workstation, I don't get a crash, but no windows and the
app is not usable.

I think the issue is this:

2020-06-23 21:45:14.699 HelpViewer[3131:3131] Exception occurred while loading m
odel: Codepoint out of range in constant string
2020-06-23 21:45:14.700 HelpViewer[3131:3131] Failed to load Gorm
2020-06-23 21:45:14.700 HelpViewer[3131:3131] Impossible de charger le fichier m
odèle principal 'Main'

Riccardo

Patrick Cardona via Discussion list for the GNUstep programming
environment wrote:

[Patrick Cardona]

Hi Riccardo,


On 2020-06-25 21:11:45 +0200 Riccardo Mottola <riccardo...@libero.it> wrote:

> Hi Patric,

>
> Patrick Cardona via Discussion list for the GNUstep programming environment
> wrote:

>> 1) I made the GNUstep core from the git repository and Clang-7, to target
>> GNUstep runtime 1.9 because my arm CPU is only 32bit, as I said in my
>> previous message.
>
>> 2) Then, I searched around from GAP (github clone of Savannah) and many
>> other source sites to grab the GNUstep tagged apps and tried to make them
>> one by one with the make way.
>> And I did not use deb source packages  because I thought they could not be
>> compatible or they should use the olg GCC to make those.
>
> GAP stuff builds with GCC fine. I think actually 99% of the apps to not
> require the new runtime.
> However, build consistently everything with the same compiler, so if you
> rebuild core gnustep, then, of course, rebuild everything.
> Don't mix.
>
>
>> P.S.1 : Yavor, I found the patched source from the Debian repo.
>> P.S.2 : Riccardo, I was not able to find the source you patched from the
>> git nor from the SVN. Is there another site I did not find ?
>> These are the sites where I searched :
>> http://cvs.savannah.nongnu.org/viewvc/gap/gap/
>
> Oh, this is historic! you landed into CVS, the project was migrated to SVN.
> We cannot disable CVS for you not to confuse things because the webpages are
> on it.
>
> The correct repository is here:
> http://svn.savannah.gnu.org/viewvc/gap/trunk/

Thank you for that up to date link. I shall verify the release of the apps I already built and I will update those outdated.

>
> (and of course, update all your other apps too if you were using them from
> GAP and want to try the latest version, the CVS one you got were years old!)
>
>> https://github.com/gnustep/gap
>
> The git mirror is out of date... it was done by Greg, but he never updated it
> after the switch from gna.
>
> Riccardo
>

Regards,
Patrick

[Patrick Cardona]

Hi Riccardo,

--
Bien cordialement,
Patrick CARDONA

On 2020-06-25 21:52:07 +0200 Riccardo Mottola <riccardo...@libero.it> wrote:

> Hi Patric,
>
>

> I think the warnings are harmless. I get them on my Laptop, yet it works.
> However, on my workstation, I don't get a crash, but no windows and the app
> is not usable.

The same. That is why I launched the app with openapp to see the debugging messages.

>
> I think the issue is this:
>
> 2020-06-23 21:45:14.699 HelpViewer[3131:3131] Exception occurred while
> loading m
> odel: Codepoint out of range in constant string

Obviously it is.
Is the CPU of your workstation based on ARM like my RPI ?
I wonder why this "Codepoint out of range" is happening in one case, but not always.

> 2020-06-23 21:45:14.700 HelpViewer[3131:3131] Failed to load Gorm
> 2020-06-23 21:45:14.700 HelpViewer[3131:3131] Impossible de charger le
> fichier m
> odèle principal 'Main'
>
>
> Riccardo
>

> Patrick Cardona via Discussion list for the GNUstep programming environment
> wrote:

[Patrick Cardona]

Hi again, Riccardo,

I did not find any path to a supplied tarball nor I could checkout the svn repository...
This command failed :

svn co http://svn.savannah.gnu.org/viewvc/gap/trunk/

Maybe a different path to get the source code ? Maybe it is not supplied for anonymous access ?

Regards

--
Bien cordialement,
Patrick CARDONA

On 2020-06-25 21:11:45 +0200 Riccardo Mottola <riccardo...@libero.it> wrote:

> Hi Patric,
>

> Patrick Cardona via Discussion list for the GNUstep programming environment
> wrote:

>> 1) I made the GNUstep core from the git repository and Clang-7, to target
>> GNUstep runtime 1.9 because my arm CPU is only 32bit, as I said in my
>> previous message.
>
>> 2) Then, I searched around from GAP (github clone of Savannah) and many
>> other source sites to grab the GNUstep tagged apps and tried to make them
>> one by one with the make way.
>> And I did not use deb source packages  because I thought they could not be
>> compatible or they should use the olg GCC to make those.
>
> GAP stuff builds with GCC fine. I think actually 99% of the apps to not
> require the new runtime.
> However, build consistently everything with the same compiler, so if you
> rebuild core gnustep, then, of course, rebuild everything.
> Don't mix.
>
>
>> P.S.1 : Yavor, I found the patched source from the Debian repo.
>> P.S.2 : Riccardo, I was not able to find the source you patched from the
>> git nor from the SVN. Is there another site I did not find ?
>> These are the sites where I searched :
>> http://cvs.savannah.nongnu.org/viewvc/gap/gap/
>
> Oh, this is historic! you landed into CVS, the project was migrated to SVN.
> We cannot disable CVS for you not to confuse things because the webpages are
> on it.
>
> The correct repository is here:
> http://svn.savannah.gnu.org/viewvc/gap/trunk/
>

[Riccardo Mottola]

Hi Patrick

Patrick Cardona wrote:
> Hi again, Riccardo,
>
> I did not find any path to a supplied tarball nor I could checkout the svn repository...
> This command failed :
>
> svn co http://svn.savannah.gnu.org/viewvc/gap/trunk/
>
> Maybe a different path to get the source code ? Maybe it is not supplied for anonymous access ?

Yes that is the path with the "view" . It is not like on github where
the path is the same.

Instructions are here:
http://savannah.nongnu.org/svn/?group=gap

but if you just need a checkout of the main trunk, no branches.. it
should be as simple as:

|svn co svn://svn.savannah.nongnu.org/gap/trunk gap
|
or if you have a firewall or such use the slower https:
||svn co https://svn.savannah.nongnu.org/gap/trunk gap

I hope that helps!

PS: yesterday I finished off most warning fixes and code cleanup. So it
should build now fine, no patches needed.
But I bet you still get the same error, since I get it on one computer
(but not the other). Will now test more.

Cheers, Riccardo
||

[Patrick Cardona]

Hi Riccardo,

On 2020-06-26 11:43:31 +0200 Riccardo Mottola <riccardo...@libero.it> wrote:

> Hi Patrick

> Patrick Cardona wrote:
>> Hi again, Riccardo,

>> I did not find any path to a supplied tarball nor I could checkout the svn
>> repository...
>> This command failed :

>> svn co http://svn.savannah.gnu.org/viewvc/gap/trunk/

>> Maybe a different path to get the source code ? Maybe it is not supplied for
>> anonymous access ?

> Yes that is the path with the "view" . It is not like on github where the
> path is the same.

> Instructions are here:
> http://savannah.nongnu.org/svn/?group=gap

> but if you just need a checkout of the main trunk, no branches.. it should be
> as simple as:

> |svn co svn://svn.savannah.nongnu.org/gap/trunk gap
> |

I was able to get the sources from the above URI. Thanks.

> or if you have a firewall or such use the slower https:
> ||svn co https://svn.savannah.nongnu.org/gap/trunk gap

> I hope that helps!

> PS: yesterday I finished off most warning fixes and code cleanup. So it
> should build now fine, no patches needed.
> But I bet you still get the same error, since I get it on one computer (but
> not the other). Will now test more.

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.

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

Regards,
Patrick

[Riccardo Mottola]

Hi,

On 6/25/20 10:48 PM, Patrick Cardona wrote:
> Obviously it is.
> Is the CPU of your workstation based on ARM like my RPI ?
> I wonder why this "Codepoint out of range" is happening in one case, but not always.

I tried this weekend on ARM, Raspberry with the latest SVN code of
HelpViewer and it seems to work for me! No crashes, files open. I use
the gcc and gcc runtime though.

I "fixed" also the blue boxes that were shown - now I know they were the
blue underlinings.... are correct now.

Big improvement I'd say.


There are some bugs I believe, especially in browsing.. the seems to be
some recursion issues, I wonder if the file is not valid or the app has
bugs (e.g. base example).


Riccardo

[Riccardo Mottola]

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"

>
> 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.

(do you have alsa, libasound and it's dev libraries installed? otherwise
try some other backend)


Riccardo

[Patrick Cardona]

Hi Riccardo,

--
Bien cordialement,
Patrick CARDONA

On 2020-06-28 20:07:46 +0200 Riccardo Mottola <riccardo...@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.

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
>
>

[Riccardo Mottola]

Hi Patrick,

thanks for your interest in GAP application, first thing.
I am revived my Raspberry PI 1 to "jessie" (still unsure if I can update
it further, but i had to reinstall, the past attempt to update it
bricked it).
Then I also have RPI3 and RPI4 to test with GNUstep. You just gave me
the impulse to buy another one and keep it as light computer at my
parents! Seems to work fine, but e.g. I noticed that for some reason
GNUMail is not 100% reliable like on x86, needs to be tested further.

Patrick Cardona wrote:
> 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' ?

Why shouldn't it? GAP contains many apps, you are not forced an "install
everything" approach.
Also, a beginner should be best served by packages - if available.

>
> 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.

You are not forced to build & install everything. Personally I don't use
those top-level makefiles either, I install and upgrade the specific apps.

> 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,

you really should be able to use both and both should work in my opinion
and then decide your won taste what to use.
If only Cythiune is giving you erros, maybe somebody has a hint on how
to fix linking!

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

if somebody can reproduce... I never compiled cynthiune on raspberry,
since I don't have sound attached to it, but I could try.

Riccardo

[Patrick Cardona]

Hi Riccardo,
Hi All


On 2020-06-29 23:26:16 +0200 Riccardo Mottola

<riccardo...@libero.it> wrote:

> Hi Patrick,
>
> thanks for your interest in GAP application, first thing.
> I am revived my Raspberry PI 1 to "jessie" (still unsure if I can
> update it
> further, but i had to reinstall, the past attempt to update it
> bricked it).
> Then I also have RPI3 and RPI4 to test with GNUstep. You just gave me
> the
> impulse to buy another one and keep it as light computer at my
> parents! Seems
> to work fine, but e.g. I noticed that for some reason GNUMail is not
> 100%
> reliable like on x86, needs to be tested further.

I am curious : what are these things not reliable within GNUMail ?

>
>
>
> You are not forced to build & install everything. Personally I don't
> use
> those top-level makefiles either, I install and upgrade the specific
> apps.

It was only for testing purpose, but I also need less apps for a dayly
use... ;-)

>
>> 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,
>
> you really should be able to use both and both should work in my
> opinion and
> then decide your won taste what to use.
> If only Cythiune is giving you erros, maybe somebody has a hint on
> how to fix
> linking!
>

Well, I made a fresh install of the Pi OS (i.e. Debian Buster, 10.4 on
my RPI 3B+) from a new SD card to avoid many upgrade issues (my
previous attempt was an upgrade from Stretch to Buster) and to be sure
to start from a clean basis.

Then I achieved to make all the GNUstep core and GWorkspace, Gorm,
Project Center, SystemPreferences, Recycler... with clang 7 and
GNUstep 1.9 runtime, behalf of the Patryck Laurent's script.

I could then make some apps, run those and retrieve my data from my
previous backup : these are AddressesManager, Affiche,
DictionaryReader, Gemas, GNUMail, Graphos, Grr, GSPdf, ImageViewer,
Ink, SimpleAgenda, Terminal and Zipper.

I applied with success the Heritage theme, tested also removable
device mounting within GWorkspace. All worked as expected.

But I was stuck again at the error I already described while making
Cynthiune app, precisely while making the ALSA bundle : undefined
version of the __malloc_initialize_hook symbol.

After some new search on the Web, I found this clue from
https://sourceware.org/bugzilla/show_bug.cgi?id=22050

> malloc: Use compat_symbol_reference in libmcheck [BZ #22050]

> Since glibc 2.24, __malloc_initialize_hook is a compat symbol. As a
result, the link editor does not export a definition of
__malloc_initialize_hook from the main program, so that it no
longer
interposes the variable definition in libc.so. Specifying the
symbol
version restores the exported symbol.

If I understand it well, I shoud supply a version number for that
symbol at linking time, but I don't kwow:
1) How to do it.
2) And not the least, what should be the appropriate version... ?

Life is so gray without music... If someone could help...

Il also was not able to make Pikopixel this time, but I must
investigate and try again, because I remember I could do it
previously...

(...)

>
> Riccardo
>

Cheers,
Patrick C.