Problem with SDK and AmiCygnix

Hi,

got my SAM some days ago.

I've installed the 4.0 SDK and some time later AmiCygnix (on OS 4.1).

Now if I start gcc I get a window asking for the volume

/Cygnix/CygnixPPC/local/bin:


It seems like gcc doesn't like the $PATH env variable that AmiCygnix sets in Cygnix:S/Cygnix-Startup.

Is this a fault of the SDK or AmiCygnix?

On classic Amiga there was a program to modify ixemul library's (and therefore gcc's) way of handling UNIX like paths. Is this also available somewhere in the SDK?

@psc

The same happened here.

I re-installed my SDK and it worked again (without any messages). Amicygnix seems to be still functionnal.

IMHO, I'd say it's a Amicygnix issue.

Cheers

Glames

@glames

To solve the problem i commented the Cygnix assign, simply put " ; " without quotes and it works

@glames

Re-installing the SDK doesn't solve the problem here.


@nubechecorre

Sorry, but I don't understand exactly what you mean

@psc

prepend ":" to the value of the PATH in "cygnix:s/sygnix-startup" line 38 to read:

SetEnv PATH :/Cygnix/CygnixPPC/local/bin:/Cygnix/CygnixPPC/bin:/Cygnix/CygnixPPC/X11R6.3/bin:/C


Jack

The PATH variable is only set for the abc-shell, because the abc-shell doesn't know "Cygnix/PATH". A special AmiCygnix version would sove this problem.

But I tried to use absolute paths (starting with "/Cygnix") whereever I could. So it should not be a big problem to change the content of "PATH".

@cygnusEd

sorry for asking a possibly dump question

How is it possible to start an abc-shell on AmiCygnix?
Thanks


nexus

@nexus

It is not possible to run the abc-shell on the AmiCygnix desktop. You have to use it as usual in an amiga shell.
There is no xterm availabale for AmiCygnix.

The abc-shell is used by AmiCygnix to run commands in an unix shell environment.

@cygnusEd

sorry for misunderstanding you with respekt to abc-shell. I know, as you've already said, that there's no xterm. I didn't want to pick on you in any way.

Thanks for your great work!

nexus

P.S. that's why i said "possibly dumb". Now i know it was not "possibly" but "dumb" :-|

double post

@Jack

Yes, this works. Thanks!

@cygnusEd
If you have the latest version of abc-shell installed, it should be looking for variables in SDK:Data/abc-shell/variables instead of the environment. If I run gcc from the abc-shell (sh) and the Cygnix PATH is set like the install script does, no requester pops up. However, if I run gcc from the Amiga shell, I get the requester. I think that gcc itself is requesting a path from the environment. It just seems strange that it only gets it from the PATH environmental variable when run from an Amiga shell. If you set a local environmental variable in an Amiga shell (set PATH /xxx) it will override the global PATH variable when gcc is run. It might be interresting to see the "getenv" function sources for newlib.library.

@cygnusEd
After further investigation, I've put my AmiCygnix on hold. In addition to minor OS4 SDK conflicts (PATH) I also had a few problems with my old 68k GeekGadgets installation that I use for compiling 68k versions of some programs. Contrary to what is stated in AmiCygnix guide, there is an OS4 version of ixemul.library (at http://strohmayer.org/) that I use with my minimal 68k GeekGadgets installation. I replaced "sh" and "make" with OS4 SDK versions, but I can compile 68k programs with GeekGadgets.

Since I had to resolve conflicts between my GeekGadgets installation and the OS4 SDK, I have a suggestion for seperating the use of abc-shell in AmiCygnix and OS4 SDK:

Add the assignment "assign CYG: CYGNIX:" to the startup script. Hex Edit all occurrances of /SDK in abc-shell to /CYG and move all the environmental variable settings from the startup script to CYGNIX:Data/abc-shell/variables.
For example in my SDK:Data/abc-shell/variables file I have: PATH=/gcc/bin:/SDK/C:/SDK/Local/C:/SDK/Local/CC:/SDK/Local/newlib/bin:/SDK/Local/clib2/bin:/C:.

The HISTFILE, SHELL and other variable can go in the variables file as well. Maybe there will be other conflicts to resolve but a little Hex Editing might be easier that compiling a seperate version of abc-shell. If you don't want to add a Data directory you could use a link like
"makelink Data TO CygnixPPC/var SOFT" (SOFT because some Amiga filesystems don't support HARD links).

@cygnusEd
My earlier suggestion eliminated my conflicts in abc-shell but I have encountered others. My CVS program uses the HOME variable to determine where put local CVS directories etc. I set the variable prior to updates or checkouts with CVS and that overwrites the AmiCygnix variable. I resolved the Amiga path conflicts between my OS4 SDK and GeekGadgets compiler setup by executing a startup script in the shell instead of the Startup-Sequence. That way the path settings are local to the shell and not available to the other compiler system (SDK and GeekGadgets run in different shells). Are the Amiga paths set in the startup file necessary?? It looks like you went to a lot of trouble to move the environmental variables to ENVARC:AmiCygnix to avoid conflicts but then added environmental variables and Amiga paths that defeat your attempts to avoid conflicts.

@xenic and others

Thank you for your replies. I will answer later. I have serious hardware problems and I have to stay in bed because of a bronchitis.

CU

@xenic

If you set up PATH as in my suggestio above (in AOS, prepend the :, I did it in cygnix:s/cygnix-startup file), gcc will work both ways.
And $HOME is a bit complicated issue. It mustn't be cygnix:home/root, but the best thing to put it in cygnix:home/username.
Don't try to link it to some dir outside. I found some apps fail to work well.
And $USER mustn't be root. Both, env:cygnix/USER and $USER are set to my username on unix boxes, ssh uses it, AOS devs:initernet/users file has it and smbfs uses it too.
It just makes things more practical and logical.

Jack

@Jack
I finally finished installing AmiCygnix and resolved some of my issues. So far everything seems to work with the PATH variable set in ENVARC:AmiCygnix/PATH and in the abc-shell variables file. I Hex Edited abc-shell to look in CYG: instead of SDK: for the Data/abc-shell/variable file and moved all the abc-shell variables from the startup to the abc-shell variables file. I also removed the path assignments from the startup file. The only catch was the initial call to sh by shexec. I solved that by adding the sh path to the variable SHEXEC_SHELL. Unfortunately, shexec gets that variable from ENVARC: instead of ENVARC:AmiCygnix but the variable is unlikely to be used by other OS4 programs so it's O.K for now. It would be nice if it could be moved to ENVARC:AmiCygnix so all the variables are in one place. In fact it would be nice to write a replacement for C library "GetEnv" that gets all the environmental variables from an AmiCygnix directory and would make AmiCygnix completely self-contained (except for the 2 amiga libraries that are installed).

I have the HOME variable set in ENVARV:AmiCygnix but no HOME: assignment and everything seems to work fine without ENVARC:HOME or the assignment.

Now that I've had a chance to take a look at AmiCygnix, it really seems a lot like GeekGadgets without the emphasis on development tools. I originally installed GG from a CD years ago to try the *nix software and not for programming. Most of it is outdated but I still have a small GG installation for compiling 68k programs.

I determined what files and paths AmiCygnix was looking for by using OS4 Snoopy but was shocked by some things I saw. If you start Snoopy after AmiCygnix is up and running you will see it doing things like opening timer.device 10 times per second. Programs I've written open devices once and close them when the program terminates. Give Snoopy a try and see what you think.

@xenic

I don't understand, why it didn't work for you to set ENVARC:PATH to your needs. The AmiCygnix startup will not touch it. The only disadvantage is, that all paths in the scripts called by abc-shell must be absolute. This should be the case in the scripts included in my packages.

The problem with shexec and SHEXEC_SHELL is a bug. I will fix this. Thanks!

It is no accident, that AmiCygnix looks like GeekGadgets. Both are unix like environments and the X11 code is based on a geekgadgets port. So don't be surprized .

The timer.device problem does not appear on my system. Which OS4 version do you use?

@cygnusEd

Quote:

It works but ENVARC:PATH creates conflicts with other programs. Some commands in the minimal GeekGadgets installation I have for compiling 68k programs use the ENVARC:PATH variable if it's set. My older version of the CVS command looks for the PATH variable. I think that the OS4 SDK gdb command gets search directories from the PATH variable. I think that the abc-shell author moved the abc-shell variables to the SDK:Data/abc-variables file to avoid such conflicts. Since abc-shell is at SourceForge it shouldn't be too hard to compile a custom version for AmiCygnix that doesn't use ENVARC:PATH.

Quote:
Glad to help and thanks for programming AmiCygnix.
Quote:

When I get the time I may try moving my 68k GG compiler to the AmiCygnix directory tree to see if I can use it from there instead of the GG environment.
Quote:

Maybe it was one of the applications and not AmiCygnix itself. I'll take another look and see if I can provide you with more details.

@xenic

Quote:

Ah - so you mean, that it would be better for you NOT to set ENVARC:PATH?

Quote:

I also have installed GeekGadgets here besides AmiCygnix. It is placed in "Cygnix:GeekGadgets68k" like in my first prerelease versions.
But I had to rename the "GG:include" and "GG:lib" directory to be able to compile AmiCygnix programs. So I can use the programs not available for AmiCygix so far. I know, it's not a good solution, if you want to compile 68k programs.

Quote:

The problem appeared here caused by "idesk", the desktop manager. Sometimes idesk seems not to be killed, when AmiCygnix is stopped. If you relaunch AmiCygnix, idesk opens the timer.device all the time. I suggest to stop idesk by sending a break signal with "Scout" (or similar program) before starting AmiCygnix again.
But most times idesk works o.k.