I have tried to make under Cygwin (i386-CYGWIN_NT-5.11), but it saids

---- SAD port is broken! ---
This ports is reported as BROKEN. BROKEN flag WOULD be kept until ports maintainer was assigned.
---- SAD port is broken! ---

Does anyone know what is the actual problem?

> I have tried to make under Cygwin (i386-CYGWIN_NT-5.11), but it saids
>
> ---- SAD port is broken! ---
> This ports is reported as BROKEN. BROKEN flag WOULD be kept until ports maintainer was assigned.
> ---- SAD port is broken! ---
>
> Does anyone know what is the actual problem?
>
BROKENマークを導入したきっかけは、外部ユーザーから Cygwin上で構築した SADでの計算結果がおかしい
(他のアーキテクチャでの実行結果と異なる)との報告にあります。その時点で、Cygwin開発環境は維持されておらず
SADの Cygwin portは長期にわたって保守されていない状態でした。具体的な不具合の内容やテストスクリプトの
提出も無く、追試・検証を行うにもすでに開発環境は維持されていない状態であり、メンテナンスを引き継ぐ人も
いなかったので 2004/08/24にBROKENマークを導入してビルドから外しました。

> > I have tried to make under Cygwin (i386-CYGWIN_NT-5.11), but it saids
> >
> > ---- SAD port is broken! ---
> > This ports is reported as BROKEN. BROKEN flag WOULD be kept until ports maintainer was assigned.
> > ---- SAD port is broken! ---
> >
> > Does anyone know what is the actual problem?
> >
> BROKENマークを導入したきっかけは、外部ユーザーから Cygwin上で構築した SADでの計算結果がおかしい
> (他のアーキテクチャでの実行結果と異なる)との報告にあります。その時点で、Cygwin開発環境は維持されておらず
> SADの Cygwin portは長期にわたって保守されていない状態でした。具体的な不具合の内容やテストスクリプトの
> 提出も無く、追試・検証を行うにもすでに開発環境は維持されていない状態であり、メンテナンスを引き継ぐ人も
> いなかったので 2004/08/24にBROKENマークを導入してビルドから外しました。

復活させるには何をすればいいですか。最近またCygwinを使いたい方がいるようなので。

> > > I have tried to make under Cygwin (i386-CYGWIN_NT-5.11), but it saids
> > >
> > > ---- SAD port is broken! ---
> > > This ports is reported as BROKEN. BROKEN flag WOULD be kept until ports maintainer was assigned.
> > > ---- SAD port is broken! ---
> > >
> > > Does anyone know what is the actual problem?
> > >
> > BROKENマークを導入したきっかけは、外部ユーザーから Cygwin上で構築した SADでの計算結果がおかしい
> > (他のアーキテクチャでの実行結果と異なる)との報告にあります。その時点で、Cygwin開発環境は維持されておらず
> > SADの Cygwin portは長期にわたって保守されていない状態でした。具体的な不具合の内容やテストスクリプトの
> > 提出も無く、追試・検証を行うにもすでに開発環境は維持されていない状態であり、メンテナンスを引き継ぐ人も
> > いなかったので 2004/08/24にBROKENマークを導入してビルドから外しました。
>
> 復活させるには何をすればいいですか。最近またCygwinを使いたい方がいるようなので。
>
BROKENフラグを外せば、ビルドフレームワークは動きますが実際にビルド出来るか・正常に動作するかに
関しては不明です(2004/08/24時点、外部から報告があっただけで SADISTでテストしている人はいないはず)

少なくとも、Cygwinの開発・試験環境の整備とその上で検証・修正作業を行うCygwin port メンテナーを
割り当てる必要があると思います
# Cygwin自身は unix互換といってもかなり癖のある環境ですから

> > > I have tried to make under Cygwin (i386-CYGWIN_NT-5.11), but it saids
> > >
> > > ---- SAD port is broken! ---
> > > This ports is reported as BROKEN. BROKEN flag WOULD be kept until ports maintainer was assigned.
> > > ---- SAD port is broken! ---
> > >
> > > Does anyone know what is the actual problem?
> > >
> > BROKENマークを導入したきっかけは、外部ユーザーから Cygwin上で構築した SADでの計算結果がおかしい
> > (他のアーキテクチャでの実行結果と異なる)との報告にあります。その時点で、Cygwin開発環境は維持されておらず
> > SADの Cygwin portは長期にわたって保守されていない状態でした。具体的な不具合の内容やテストスクリプトの
> > 提出も無く、追試・検証を行うにもすでに開発環境は維持されていない状態であり、メンテナンスを引き継ぐ人も
> > いなかったので 2004/08/24にBROKENマークを導入してビルドから外しました。
>
> 復活させるには何をすればいいですか。最近またCygwinを使いたい方がいるようなので。
鎌田さん経由なので、誰がやったか知らないのですが WindowsXPへの re-portを試みた人がいるようです
質問が来ただけで、成功・失敗の報告も成果の公開も現時点ではありません
http://acc-physics.kek.jp/cgi-bin/SAD-BBS/wforum.cgi?mode=allread&no=512&page=0

　確かに、吉本さんも言うように、今やVmwareでlinuxなどを走らせた方が便利なので、いまさらcygwinをやってもしょうがないですね。

　　そんなことはないと思います。ELEGANT、PARMELA など、まずは cygwin で走らせるのが便利な
コードも多々ありますので、SAD と同じ環境で実行できることには大きなメリットがあります。
昔のビルドは cygwin で走る（一時期、cygwin のせいでダメでしたが、最新の cygwin では
また走るようになりました）ので、それを大事に使っています。(BROKEN 外してコンパイルしても、
最後までコンパイルは通りません。X、python、TclTk 全てやめてもダメです。 ）　どうしても
cygwin でやりたい人には、（その人がそもそも今の SAD をダウンロードできることを確認した上で、）
昔のバージョンをあげています。
　　最新の SAD が cygwin で走ると、それはそれで有り難いことです。

> 　　そんなことはないと思います。ELEGANT、PARMELA など、まずは cygwin で走らせるのが便利な
> コードも多々ありますので、SAD と同じ環境で実行できることには大きなメリットがあります。
> 昔のビルドは cygwin で走る（一時期、cygwin のせいでダメでしたが、最新の cygwin では
> また走るようになりました）ので、それを大事に使っています。(BROKEN 外してコンパイルしても、
> 最後までコンパイルは通りません。X、python、TclTk 全てやめてもダメです。 ）　どうしても
> cygwin でやりたい人には、（その人がそもそも今の SAD をダウンロードできることを確認した上で、）
> 昔のバージョンをあげています。
> 　　最新の SAD が cygwin で走ると、それはそれで有り難いことです。
>
最新の SADがコンパイルできないのは当然だと思います
cygwinが unix互換環境とはいえ 100%互換では無いので、コードの追加と削除が行われ
かれこれ4年以上 cygwin上の検証が行われて居ません
検証や修正を行うメンテナーが居ないと維持できません、だれかやりませんか？
# 学生時代は、日本語 TeX文書の PDF化用に VMwareで
# Windowsを飼っていたのでその上で作業が出来たのですが
# dvipdfmxが開発されで Acrobatが不要になった&VMwareが
# 古くなって環境が維持出来なくなったという理由から私の
# 開発環境は消滅しました

cygwin環境の維持と cygwin上での検証と開発・保守作業を行う人員が確保できないのであれば、
QEMUや VMware player用のSADがインストールされた PC-unixの disk imageを配布するのが
一番楽なWindows対応だと思います

Linuxの場合 SAD clusterで検証に使えるのは alsad3のみで、かなり古いLinuxなので実は
最新の Linux環境では継続的な動作検証が行われていない問題も有りますが...

> Linuxの場合 SAD clusterで検証に使えるのは alsad3のみで、かなり古いLinuxなので実は
> 最新の Linux環境では継続的な動作検証が行われていない問題も有りますが...

alsad3も多分退役するので、SAD clusterからLinuxな環境はなくなる予定です。
ただ、まあ、個人的にVMware上ですが、最近のLinuxな環境（Ubuntu 8.0.4）
を入れて、GCC 4.4.0及びIntel Compiler 10.1でamorita-branchの方は動く
ことは確認しています。

> > Linuxの場合 SAD clusterで検証に使えるのは alsad3のみで、かなり古いLinuxなので実は
> > 最新の Linux環境では継続的な動作検証が行われていない問題も有りますが...
>
> alsad3も多分退役するので、SAD clusterからLinuxな環境はなくなる予定です。
> ただ、まあ、個人的にVMware上ですが、最近のLinuxな環境（Ubuntu 8.0.4）
> を入れて、GCC 4.4.0及びIntel Compiler 10.1でamorita-branchの方は動く
> ことは確認しています。
>
amorita-branchが動くことは CVS MAIN trunkが動作する保証に成らない点は注意が必要です

最近のコンパイラサポート回りのコードは MAIN trunk側へはバックポートされていません
正確には全部バックポートすると、ISO Fortran2003を前提とするコードが入るので
古い Fortranコンパイラが全滅します(Intel Fortran 8.1 or prior/GCC 4.2 or prior/おそらくDEC Fortranも)
# 古い Fortran規格には存在しない機能をベンダー拡張で実装しているコードを
# 現行のFortran規格(現時点では2003/もうすぐ 2008が出る？)で標準化された機能へ
# 置き換える作業が進行中(現行規格に対応した Fortranコンパイラへの移植性が向上します)

Subversion vs CVSと異なるレポジトリ間で、差分を分割しての検証やマージ管理は結構面倒なんで
致命的なバグやSAD Clusterの運用に必要なコード以外はバックポートしたくない

>
> cygwin環境の維持と cygwin上での検証と開発・保守作業を行う人員が確保できないのであれば、
> QEMUや VMware player用のSADがインストールされた PC-unixの disk imageを配布するのが
> 一番楽なWindows対応だと思います
>
> Linuxの場合 SAD clusterで検証に使えるのは alsad3のみで、かなり古いLinuxなので実は
> 最新の Linux環境では継続的な動作検証が行われていない問題も有りますが...

個人的にはLinuxもできるだけ最新版で検証しているつもりですが。

> > cygwin環境の維持と cygwin上での検証と開発・保守作業を行う人員が確保できないのであれば、
> > QEMUや VMware player用のSADがインストールされた PC-unixの disk imageを配布するのが
> > 一番楽なWindows対応だと思います
> >
> > Linuxの場合 SAD clusterで検証に使えるのは alsad3のみで、かなり古いLinuxなので実は
> > 最新の Linux環境では継続的な動作検証が行われていない問題も有りますが...
>
> 個人的にはLinuxもできるだけ最新版で検証しているつもりですが。
>
この辺の検証状況は公開されていないのでを Wikiか何かで公開した方が良いかもしれませんね
# SADISTに入っている人でも、誰がどの環境でどの程度の頻度でテストしてるかは知らないのでは？

o 検証されたソースコードツリー(MAIN trunkなら CVS symbolic tag or date tag)
- 編集された working copyは再現性に問題がある
o 検証環境(CPU種別/OS&コンパイラのバージョン[安定版で無ければ snapshot date])
o コンパイル時の設定(sad.conf等)
o 何時・誰によって検証が行われたか
o どうのレベルの検証が行われたか
- sad1.exeのビルドの可否
- script/bench2.sadの正常動作(正常な動作の定義が必要ですが)
- 修正済みで有るはずのバグの退行試験
etc...

それとも、検証用のマシンを用意して毎日 MAIN trunkの HEADを自動的にビルド＆テストコードを
走らせてリファレンスと比較してステータスレポートを生成すべきか？
# 自動ビルドを実行すれば、コンパイル不能になる commitは自動的に発見できると思います
# テストコードに付いては、どれだけまじめにテストを書くかに依存しますが

　　PFでは今年の夏、大がかりに計算機環境の更新が行われます。現在のところ、PF 制御系には
MAC はほとんど存在せず、端末などは Linux （Scientific linux か CentOS）で、メインの
サーバは HP-UX です。更新後、メインのサーバも Linux （RedHat EL V4 64bit) になります。
SAD 他、64 bit 非対応のアプリケーションは 32bit 互換サーバ、またはバーチャルマシン上で
動かすことになる様ですが、どちらにせよ、PFでは今もこれからもほぼ全て Linux です。^_^;
　
　　制御の上でも、特に RF はほとんど SAD ですし、電磁石も一部 Python を除いて、SAD が
多いです。運転上からも、SAD はとても重要です。
　　アップデートされる度に SAD を新しくしてはいませんが、一応、時々テストはしています。

> 　　そんなことはないと思います。ELEGANT、PARMELA など、まずは cygwin で走らせるのが便利な
> コードも多々ありますので、SAD と同じ環境で実行できることには大きなメリットがあります。
> 昔のビルドは cygwin で走る（一時期、cygwin のせいでダメでしたが、最新の cygwin では
> また走るようになりました）ので、それを大事に使っています。(BROKEN 外してコンパイルしても、
> 最後までコンパイルは通りません。X、python、TclTk 全てやめてもダメです。 ）　どうしても
> cygwin でやりたい人には、（その人がそもそも今の SAD をダウンロードできることを確認した上で、）
> 昔のバージョンをあげています。
> 　　最新の SAD が cygwin で走ると、それはそれで有り難いことです。
>
SADへ Pythonを組み込む機能ですが、昔は現在の SAD/Tkinterではなくpython経由で
tkを呼び出すために使っていたそうですが(Packages/Tkinter.nなどに名残がある)、
現在でも Pythonインタープリターの組み込み需要はあるのでしょうか？

o Packages/*.nなどでは、利用されていないように見える
o Pythonの改訂に伴う Python <-> SAD間の相互接続の保守が必要
なので、需要がないならコードを削除したいところなのですが、どうでしょう？

現在は、CVS repositoryのミラーが公開されているので、過去のコードを
取り出すことも出来ますから、動作や保守が保証できないコードは
事情の分らない一般ユーザーが誤って使うことの無いように trunkから
削除すべきでは無いでしょうか？

# FFS組み込みの軌道補正関連も、mcmess_()@src/tffsa.fで
# Orbit Correction commands will be removed soonと予告されていますが
# まだ入ったままで呼び出せますが、正常に動かないものも有ったのでは無いでしょうか？

KEKBではOracle databaseを読むのにPython経由で行っていますが(Oracle.n)、実はSADの中に組み込まなくても実行可能だと思います。他の例は知りません。

> KEKBではOracle databaseを読むのにPython経由で行っていますが(Oracle.n)、実はSADの中に組み込まなくても実行可能だと思います。他の例は知りません。
>
Oracle.nは、python外部コマンドを rsh経由で別ホストに起動して、pythonコード自身は
-cオプションで引き渡し、結果を標準出力から一時ファイルにリダイレクトしたものを
Fortran I/O経由で読んでいるので SAD本体側に組み込まれた Pythonは使っていません

SAD組み込みの Pythonを呼び出している例は、Tkinter.nの Pythonシンボルで
Wishシンボル同様に コンソールから一行入力を受けて PyEvalString[]で
組み込み pythonインタープリタに処理させています(おそらくテスト用のコード)

2008/07/04現在の Cygwinに関する情報をまとめると

o Cygwin portにはメンテナーが居ない
o Cygwin上では、BROKENフラグを外しても、そのままではコンパイルできない
- 2008年 1月時点でコンパイルに成功した人はいるようです(方法は未公開)
Ref: http://acc-physics.kek.jp/cgi-bin/SAD-BBS/wforum.cgi?mode=allread&no=512&page=0
o Cygwinを使って動かしたいという需要はある

o 現状で Windows上で SADを動かす方法は以下の通り
A. CVS repositoryから古いソースコードツリーを取り出して、Cygwin上でコンパイルして使う
B. QEMU/VMware Player等の仮想マシン上で PC-unixを動かし、その上で unix版の最新のSADを使う

(A)の場合は、「新たに実装された新機能が使用できない」・「既知のバグが未修整である」ので注意が必要です
「Cygwin上で正常に動作する最も新しいソースツリーを指定する CVS date tagは何時か？」という
問題があります

Cygwinサポートを復活を望む場合、だれかがメンテナーになって再移植する or No.512の成果を
ベースに作業するなどのアクションを起こす必要があります
# X-Serverを使わない Nativeな Windows化をするにはさらに Tkinter回りの改良作業が必要です
# SAD/Tkinterから X11依存性を分離する or X11へのアクセス関数を仮想化する辺りの作業は
# MacOSXでの Aqua/Tkサポートとある程度重なると思います(これも、開発が止まってますが)

I have got partial success on cygwin. I will soon chick-in.

Both amida and bench2.sad looks to work properly.
I had to tweak tfNetworkIO_.c to skip a lot of undefined symbols.
Tcl/Tk 8.5 was not able to link with hundreds of undefined external symbols.

Machine: Mac Book Pro 2.2 GHz
OS: Windows XP SP3 via VMWare Fusion 2.0b1 on Mac OS 10.5.4
Cygwin/X 6.8.99.901-4
SAD1.0.10.2.7a1
Tcl/Tk 8.4.14


Result of bench2.sad:
*********** summary of the bench mark
Function Test 3.994999974966049
Optics Test5.357999801635742
Tracking Test7.360001564025879
Matching Test4.916999816894531
Overall Score (smaller is faster): .278816976007961

Environment Variables:
PWD=/home/oide/SAD/oldsad
TERM=dumb
TERMCAP=emacs:co#80:tc=unknown:
EMACS=t
MANPAGER=cat
EMACSPID=2628
XTERM_SHELL=/bin/tcsh
XTERM_LOCALE=C
XTERM_VERSION=Cygwin 6.8.99.901(229)
WINDOWID=12582942
XAUTHORITY=/home/oide/.Xauthority
COMPUTERNAME=WINXP
SESSIONNAME=Console
NUMBER_OF_PROCESSORS=1
DISPLAY=:0.0
PROGRAMFILES=C:\Program Files
PROCESSOR_REVISION=0f08
LOGNAME=oide
MACHTYPE=i386
TMP=/cygdrive/c/DOCUME~1/oide/LOCALS~1/Temp
SYSTEMROOT=C:\WINDOWS
VENDOR=intel
PROMPT=$p$g
COMSPEC=C:\WINDOWS\system32\cmd.exe
HOMEDRIVE=C:
OSTYPE=cygwin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
SHLVL=2
HOME=/home/oide
WINBOOTDIR=C:\WINDOWS
PROCESSOR_ARCHITECTURE=x86
!C:=C:\cygwin\home\oide
LOGONSERVER=\\WINXP
USERPROFILE=C:\Documents and Settings\oide
CLIENTNAME=Console
SYSTEMDRIVE=C:
FP_NO_HOST_CHECK=NO
PATH=/home/oide/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/users/oide/bin:/Users/oide/SAD/oldsad/bin
PROCESSOR_LEVEL=6
USERNAME=oide
HOSTTYPE=i386-cygwin
XNLSPATH=/usr/X11R6/lib/X11/locale
TEMP=/cygdrive/c/DOCUME~1/oide/LOCALS~1/Temp
COMMONPROGRAMFILES=C:\Program Files\Common Files
XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
GROUP=筏
USER=oide
!::=::\
XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
OS=Windows_NT
ALLUSERSPROFILE=C:\Documents and Settings\All Users
USERDOMAIN=WINXP
CVSROOT=:ext:acsad4.kek.jp:/SAD/cvsroot
WINDIR=C:\WINDOWS
SHELL=/bin/tcsh
HOST=winxp
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 8, GenuineIntel
XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
MANPATH=/Users/oide/man:/usr/local/share/man:/usr/share/man:/usr/X11R6/man:/SAD/share/TclTk/Darwin/man
APPDATA=C:\Documents and Settings\oide\Application Data
REMOTEHOST=
HOMEPATH=\Documents and Settings\oide
COLUMNS=132


sad.conf:
# =================================
# New Makefile -- Local Configuration Part Sample
#

## Compiler setting examples

# -- Interl C/Fortran Compiler 7.1 --
#COMPILER=Intel
#FC=ifc
#CC=icc

# -- Interl C/Fortran Compiler 8.x --
#COMPILER=Intel
#FC=ifort
#CC=icc
##SYS_FOPT+=-vms -ccdefault list
#SYS_FOPT_ENABLE_BACKSLASH_ESCAPE=-assume bscc
#SYS_DEPOBJ+=sim/intel_fortran8.o

# -- GNU Compiler Collection 4.1 or 4.2 --
SYS_FOPT= -Wall
_USE_GFORTRAN= YES
_USE_G95= NO
COMPILER=GNU
SYS_COPT= -Wall -std="gnu99"
CC=gcc
ifeq ($(OSTYPE),cygwin)
COPT= -D CYGWIN
FC=g77
FOPT= -O2 -fno-second-underscore -fdollar-ok -fargument-alias -mpreferred-stack-boundary=4 -mfancy-math-387 -fbackslash
LDOPT= -enable-auto-import -v
else
FC=gfortran
FOPT= -O2 -fno-second-underscore -fdollar-ok -fargument-alias -mpreferred-stack-boundary=4 -mfancy-math-387 -frecursive -fbackslash -std=legacy -fall-intrinsics
endif

#HAVE_F_LNBLNK=NO
#SYS_DEPOBJ+=sim/unix_fortran_.o sim/fseek_Dummy_.o

# -- Debugging source tree --
#COPT=-g -O1

# -- Debugging memory allocator --
#COPT+=-DDEBUG_MEMORY

# -- Debugging memory usege --
#COPT+=-DUSE_ELECTRICFENCE -DUSE_ELECTRICFENCE_FREECHECK
#EXE_LIBS+=-L/usr/local/lib -lefence

## SAD root directory
#SAD_ROOT=/usr/local/SAD

## Contrib source archive directory
#SOURCE_ARCHIVE_DIR=/usr/ports/distfiles

## X11 setup
#
USE_X11=YES
#X11_PREFIX=/usr/X11R6
##X11_INCDIR=$(X11_PREFIX)/include
##X11_LIBDIR=$(X11_PREFIX)/lib
##X11_LIBS=-lX11

## Tcl/Tk setup
#
USE_TCLTK=YES
##BUILD_TCLTK=YES
##USE_TCLTK_SHARED_LIBRARY=YES
##TCLTK_GUI_BACKEND=X11|AQUA
##TCLTK_FONT_SYSTEM=Xlib|Xft
##TCLTK_VERSION=8.5a5|cvs|8.4.14
ifeq ($(OSTYPE),cygwin)
TCLTK_VERSION=8.4.14
endif
##TCLTK_PREFIX=$(SAD_ARCH_DIR)
##TCLTK_INCDIR=$(TCLTK_PREFIX)/include
##TCLTK_LIBDIR=$(TCLTK_PREFIX)/lib
##TCLTK_LIBS=-ltk$(TCLTK_FEATURE_VERSION) -ltcl$(TCLTK_FEATURE_VERSION)

## Python setup
#
#USE_PYTHON=YES
##BUILD_PYTHON=YES
##USE_PYTHON_THREAD=YES
##PYTHON_VERSION=2.4
##PYTHON_PATCH_LEVEL=1
##PYTHON_PREFIX=$(SAD_ARCH_DIR)
##PYTHON_INCDIR=$(PYTHON_PREFIX)/include/python$(PYTHON_VERSION)
##PYTHON_LIBDIR=$(PYTHON_PREFIX)/lib
##PYTHON_LIBS=-lpython$(PYTHON_VERSION)
##PYTHON_PATH=$(PYTHON_PREFIX)/lib/python$(PYTHON_VERSION)

## EPICS setup
#
#USE_EPICS=YES
#EPICS_INCDIR=$(EPICS_PREFIX)/include
#EPICS_LIBDIR=$(EPICS_PREFIX)/lib
#EPICS_LIBS=-lca -lDb -lCom

## for KEK-B EPICS setup
#USE_KEKB_EPICS=YES

# --- don't touch ---
ifeq ($(USE_KEKB_EPICS),YES)
KEKB_EPICS_ARCH=Unknown

ifeq ($(OS_NAME),Linux)
ifeq ($(CPU_ARCH),i386)
KEKB_EPICS_ARCH=Linux
endif
endif

ifeq ($(OS_NAME),OSF1)
ifeq ($(CPU_ARCH),Alpha)
KEKB_EPICS_ARCH=alpha
endif
endif

ifeq ($(OS_NAME),Darwin)
ifeq ($(CPU_ARCH),i386)
KEKB_EPICS_ARCH=darwin-x86
EPICS_PREFIX=/proj/epics/R314/R3149/base
EPICS_LIBS=-lca -ldbStaticHost -lCom
COPT+=-I$(EPICS_PREFIX)/include/os/Darwin
endif
ifeq ($(CPU_ARCH),PowerPC)
KEKB_EPICS_ARCH=darwin-ppc
EPICS_PREFIX=/proj/epics/R314/R3149/base
EPICS_LIBS=-lca -ldbStaticHost -lCom
COPT+=-I$(EPICS_PREFIX)/include/os/Darwin
endif
endif

ifeq ($(OS_NAME),HP-UX)
ifeq ($(CPU_ARCH),PA1.0)
KEKB_EPICS_ARCH=hp700
endif

ifeq ($(CPU_ARCH),PA2.0)
KEKB_EPICS_ARCH=hppa8k
endif
endif

ifeq ($(KEKB_EPICS_ARCH),Unknown)
$(error Unknown architecture)
else
USE_EPICS=YES
EPICS_PREFIX?=/proj/epics/R313/base
EPICS_LIBDIR=$(EPICS_PREFIX)/lib/$(KEKB_EPICS_ARCH)
endif
endif # USE_KEKB_EPICS==YES

# End of File

By the way, the results of bench2.sad on the same machine were

Mac OS 10.5.4 (gcc4.3):
*********** Summary of the bench mark
Function Test 2.879933007061481
Optics Test4.164700984954834
Tracking Test5.793102264404297
Matching Test3.715328216552734
Overall Score (smaller is faster): .210998286271379

Kubuntu 8.0.4(gcc4.3) on VMWare Fusion:
*********** summary of the bench mark
Function Test 3.508219003677368
Optics Test5.620351314544678
Tracking Test8.020502090454102
Matching Test4.908306121826172
Overall Score (smaller is faster): .27674943563484

with the common sad.conf .

In this case, SAD directory is located in Mac OS's volume which is mounted to Win XP as a network drive. Then ':' in the filename is translated to '%003A' (5 characers). Actually some patch files uses ':' in their names. I wonder why they do this but it should be avoided if possible. Then the make file for cygwin was modified so as to replace ':' with '?????', which is just ugly.
I have no idea what happens when the SAD directory is created in a Windows volume or in a cygwin volume.

> In this case, SAD directory is located in Mac OS's volume which is mounted to Win XP as a network drive. Then ':' in the filename is translated to '%003A' (5 characers). Actually some patch files uses ':' in their names. I wonder why they do this but it should be avoided if possible. Then the make file for cygwin was modified so as to replace ':' with '?????', which is just ugly.
> I have no idea what happens when the SAD directory is created in a Windows volume or in a cygwin volume.
>
変換されるのは、VMWareが MacOSX上の Local FSを CIFSでエクスポートするときか、
Windowsが CIFSマウントする際に変換されているのだと思われる

ローカルNTFSを Cygwin側で bin modeでマウントした状態でbashから「echo foo >bar:zoo」を実行すると
「bar」というファイルが出来るので 「:」から先の PATH名が無視されている
Cygwin側の環境変数設定で挙動が変わるかも知れないが、Defaultの状態ではこの点に関しては
unix互換では無い
# POSIX的にはどうなんだろう？

> I had to tweak tfNetworkIO_.c to skip a lot of undefined symbols.
>
tfNetworkIO_.cに関しては、Cygwinが RFC 3494/2553で定義された IPv6 APIを
実装していないのが原因なので、tfNetworkIO_.cを変更するのではなく
IPv6 APIを実装するのが筋で、実際にそういう作業をしている人々がいるようです

Cygwin/w32api 1.5.25-15 IPv6 extension
http://win6.jp/Cygwin/index-j.html

> > I had to tweak tfNetworkIO_.c to skip a lot of undefined symbols.
> >
> tfNetworkIO_.cに関しては、Cygwinが RFC 3494/2553で定義された IPv6 APIを
> 実装していないのが原因なので、tfNetworkIO_.cを変更するのではなく
> IPv6 APIを実装するのが筋で、実際にそういう作業をしている人々がいるようです
>
> Cygwin/w32api 1.5.25-15 IPv6 extension
> http://win6.jp/Cygwin/index-j.html

このページの通りにやってみました(不達成動詞)が、例えば /usr/include/ucontext.h ができないので、あまり状況は改善していないと思います。

> > > I had to tweak tfNetworkIO_.c to skip a lot of undefined symbols.
> > >
> > tfNetworkIO_.cに関しては、Cygwinが RFC 3494/2553で定義された IPv6 APIを
> > 実装していないのが原因なので、tfNetworkIO_.cを変更するのではなく
> > IPv6 APIを実装するのが筋で、実際にそういう作業をしている人々がいるようです
> >
> > Cygwin/w32api 1.5.25-15 IPv6 extension
> > http://win6.jp/Cygwin/index-j.html
>
> このページの通りにやってみました(不達成動詞)が、例えば /usr/include/ucontext.h ができないので、あまり状況は改善していないと思います。
>
ucontext.hは、 The Single UNIX&#174; Specification, Version 2辺りで規定されている
User Thread Context関連のヘッダー(getcontext/swapcontext/setcontext関数など)
なので、RFC 3494/2553(Network API)とは無関係ですからその部分は改善しません

Cygwinは、現時点では User Thread Contextが未実装だそうですが、
sigaction(2)での POSIX SA_SIGINFOハンドラは、第三引数で割り込みの
User Thread Contextを受け取ることになっているので，SA_SIGINFOマクロが
定義されている状況で ucontext.hが未実装というのは POSIX/SUS的には
かなり不完全な実装だと思います

> > I had to tweak tfNetworkIO_.c to skip a lot of undefined symbols.
> >
> tfNetworkIO_.cに関しては、Cygwinが RFC 3494/2553で定義された IPv6 APIを
> 実装していないのが原因なので、tfNetworkIO_.cを変更するのではなく
> IPv6 APIを実装するのが筋で、実際にそういう作業をしている人々がいるようです
>
> Cygwin/w32api 1.5.25-15 IPv6 extension
> http://win6.jp/Cygwin/index-j.html

同様に他ではnetdb.hで定義されているいくつかのsymbolもダメですね。