ちょっとは人のためになる事をしないとインターネットコミュニティーの皆様に申し訳がないかと思いながら、自分の備忘録ていどでしかなく、実際の所たいした情報も提供できないでいるブログ
× [PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
volume "/hoge" does not support Extended Attributes or read-only volume
extended attributes が有効になっていない。/etc/fstabにて
UUID=f9d0cd90-5d2d-4379-9025-c69eb58e7006 /hoge ext4 defaults,user_xattr 0 0
オプションに user_xattr を追加する
ディレクトリ内の ._ で始まるファイルを消したらなおった
sys_lsetxattr("/hoge"): Permission denied
ログインユーザーに公開しているディレクトリのトップ(afpd.conf path=のディレクトリ)の書き込み権限を与える。サブディレクトリに対しては書き込み許可の必要は無い。トップのみで良い。 ログイン可能ユーザーのグループをつくり、 groupadd afpuser usermod -G smbuser ログインユーザーID chgrp afpuser /hoge chmod g+w /hoge など。
posix_acls_to_uaperms(obj, path, st, ma) failed: Too many levels of symbolic links
acl = acl_get_file(path, ACL_TYPE_ACCESS) failed: Too many levels of symbolic links
間違って、自分をさしているシンボリックリンクがあると発生した。 シンボリックリンクを消す。 PR
Visual Studio 2012 / Visual C++ ATL Wizard で作成したオブジェクトが、Local Serverでは作成できるが、Serviceとして登録した場合に、オブジェクトが作成できない問題の解決方法。
対象のクラスの .rgs ファイルに AppId 値を追加する。 再コンパイルを行う xxxx.exe /service で登録する HKCR { NoRemove CLSID { ForceRemove {6E94C55F-4AE0-45F1-A6A1-47C97110E1A4} = s 'Manager Class' { ForceRemove Programmable LocalServer32 = s '%MODULE%' { val ServerExecutable = s '%MODULE_RAW%' } val AppID = s '%APPID%' TypeLib = s '{FDEF3EA6-16EE-4421-996D-E615C277C041}' Version = s '1.0' } } }
error: call to implicitly-deleted default constructor of '...'
キューのキャンセル
- [NSOperation cancel] を受けたら、isFinished = YES に移行しないと、オペレーションがキューに溜まったままになる。特に、開始していないオペレーションに対する処理をわすれがち。
要約:
詳細:
deploy ができなくなった、とおもったが、とても初心者な勘違い。
Tomcat Web Application Manager の Deploy - War file to deploy で、ファイルをアップロードすると、そのままデプロイ出来るのかと思っていたが、そうではない。
検索すると、server.xml のunpackWARs や autoDeploy に関するが引っかかるが、関係なかった。
アップロード後、なにもエラーないので(ここが勘違い)、デプロイできているのかとおもいきや、コードの変更が反映されない。エラーメッセージがめだたなくて、気づいていないだけだった。エラーメッセージは、画面上部、Message: に表示される。失敗メッセージが <TT> の目立たないフォントで表示されてて、気づかなかったのが敗因。
Xcode 4.4 にしたら、既存の git のワーキングコピーに対するソースコントロールができなくなった。
Project Navigator のソースコントロール状態を示す "M" とか"A"とか "C"のマークが出ない。Version Editor 画面でリビジョン比較ができない。プロジェクトと git との関連性が失われたような感じ。 手動(コマンドラインなど)で git の操作をしていたプロジェクトで発生するようだ。Xcode 4.4 より前は、フォルダに .git があるだけで良かったが、Xcode 4.4 になり挙動がかわったようだ。 解決方法: 問題があるプロジェクトが開いていたら閉じる Organizer の Repositories を開く 左下の '+' で "Add Working Copy..." ".git" がおいてあるフォルダを指定 Organizer の Projects を開く プロジェクトをオーガナイザーから削除 左の一覧で Ctrl+Click して Remove From Organizer 一覧から削除されるだけで、プロジェクト本体に影響はない プロジェクトを開く 以上で直るはず
インストール手順にしたがったら CUPS で一覧表示されなかったのでメモ。
cups-pdf のパーミッションに注意。 http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/download.shtmlからソースのtarballをダウンロードする。 http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/documentation.shtmlの Installation に準じてインストールするが、追加作業を要する。
修正不要。オリジナルのままでかまわない。 この通りコンパイルする。 /usr/lib/cups/backend/cups-pdf のパーミッションを調整する必要がある。 これをしないと、CUPSが認識しない。 修正不要。オリジナルのままでかまわない。 /usr/share/cups/model/Generic はないので mkdir する必要がある。 というか、/usr/share/cups/model にコピーすれば良い。
(2012/1/10修正追記)
Xcode で Simulator を使ったデバッグを開始しようとすると、"Attaching to アプリ名" のところで常にハングしてデバッグセッションを開始できない プロジェクトができてしまった。 Stack Overflow のこの問題のスレッドには多数のレスがあり、原因・解決方法も多種多様のようだ。 私の場合、 One more possible solution: I had my Resources folder added to the project as a folder reference (the blue folder icon). That caused the trouble, after adding the folder as a group the problem went away. まさに、この状況で発生した。ハングアップはリソースを Folder Reference で追加した直後だった。 レスにあるように Folder Reference を Folder As Group に変えてみたが、それだけでは解消しなかった。
私の場合、この4つを行ったら、ハングアップが解消された。
CIContext を作る等やってみていましたが、なかなかうまく行かない。
この方法が簡単なようです。
ipautil について。
iOS 開発では、"Archive"でアーカイブを作り、Share... で Adhoc 配布します。 Adhoc配布をするパッケージは、社内サーバーの所定の位置に配置して、 テスターがダウンロードしておのおのインストール、テストを行うのが 普通だと思います。 テスターの人にわかりすいよう、ファイルをアプリケーションごとのディレクトリに分けていれたり、ファイル名にリリース日付を入れたり、バージョン番号を入れたりしたいものです。 ところが、Xcode の Share... では app.ipa というファイル名がデフォルトになります。配布する人(私)は、わかりやすいファイル名を、間違えないよう注意しながら、手入力しなければなりません。 この入力は結構神経を使います。さらにまずいことに、この作業ステップは、コーディングを散々したあげく、テストがやっと通り、ああもうすぐにでもこいつをリリースしちゃって寝たい、という極限状況で訪れます。 一刻も早く寝たいのです。格納場所が間違っていてテスターにファイルがわたらなかったり、バージョン番号が間違っていて、どのファイルが最新?みたいな質問で起こされたくありません。 そこで、アプリケーション名やバージョン番号を ipa ファイルから抜き出すユーティリティを作りました。これを使えば、決まった形式で、決まった場所にコピーするシェルスクリプトを書くことができます。 こんな者を使うのはプロの方だけだろうとおもうので、ソース配布です。 BSDライセンスで ここに置きました。 Xcode 4.2 でビルドできます。libarchive が必要です。 libarchiveは、ふつうに configure / make したもので OK です。
Xcode 4.2 で iOS のスタティックライブラリを作り、自分で利用する
スタティックライブラリとアプリケーションは別のプロジェクトとする。
せっかちな人用
ライブラリを使う側:
ライブラリ側:
一般的な考慮事項 ライブラリを利用する場合、
の二点が必要になる。前者はコンパイラーの -I オプションに関する設定であり、後者はリンカーの -L のディレクトリ指定、-lのライブラリ指定に関わる設定だ。 両者を適切に設定しないと、コンパイルできない(.hが見つからない)、リンクできない(未定義シンボル)といったトラブルになる。 スタティックライブラリの作成方法 プロジェクト作成時に、Cocoa Static Library を選択する。ここまでは簡単。 ライブラリの名前のつけ方に注意。 Unix系のライブラリは libなんとか.a というファイル名とするのが慣例で、この名前にするために、プロジェクト名は、「なんとか」の部分だけを指定する。 例えば、libpicture.a を作ろうとしている場合、Xcode でのプロジェクト名は "picture" だけを指定する 。"libpicture"などと指定すると、liblibpicture.a が作られてしまい気持ちが悪い。あとで修正するのも面倒だ。 Xcode プロジェクトにライブラリのプロジェクトを追加する。 アプリケーションのプロジェクトに、スタティックライブラリの .xcodeproj ファイルを追加する。追加するのは .xcodeproj であり、スタティックライブラリプロジェクトのディレクトリではない。
スタティックライブラリがヘッダーファイルを公開する方法 スタティックライブラリは、ライブラリ関数のプロトタイプや各種定義類が入ったヘッダーファイルを提供する。automake/autoconfを使う場合は make install で /usr/local/include などにコピーするのだが、アーキテクチャの違う iOS ライブラリをそのような場所にコピーする訳にもいかない。 Xcodeでは少し変わったビルド方法をとっている。公開するヘッダーファイルをプロジェクト内の領域(DerivedData下)にヘッダーファイルをコピーして、依存関係のあるプロジェクトでヘッダーファイルを参照する仕組みだ。 公開したいヘッダーファイルを Project Navigator(⌘1)で選択し、File Inspector(Option+⌘+1)のTarget Membershipでライブラリターゲットのメンバーとするよう、チェックを入れる また、Target Membership の "Project" となっている部分を Public に変更する。
スタティックライブラリが公開したヘッダーファイルをインクルードする設定。 プロジェクト内の領域(DerivedData下)にコピーされたヘッダーファイルを利用できるように設定する。ライブラリを使用するターゲットの "Header Search Path" に下記の2行を追加する。 $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/usr/local/include $(INSTALL_ROOT)/usr/local/include (2011/10/18追記: Archive時、これがないと include が見つからない) 検索ボックスで "header search" と入れると見つけやすい。設定項目の表示が Basic だと出ないので注意。 プロジェクトレベルの Header Search Paths に、本設定を追加しても良い。
依存関係および、リンク対象とする設定を行う
Link Binary With Libraries に、リンクしたいライブラリを追加する。
以上。
Xcode3 で Adhoc ビルドをする場合は、Adhoc 用のビルドコンフィグレーションを作り、AdHoc の Provisioning Profile を設定する。
Xcode4 では、Build -> Archive でアーカイブ用ビルド(通常は Release コンフィグレーション) を行い、アーカイブ後に Provisioning Profile を指定するので、AdHocビルドが不要になる。 不要になった AdHoc の消し方。 プロジェクトナビゲーターでプロジェクトを選択する。 Info タブを選択する。 iOS Deployment Target の下、"Configuration" 内の AdHoc (削除したいコンフィグレーション)を選択する Delete キーを押す (または、リストの下にある - ボタンを押す)
デバッグ時のコマンドライン引数の与え方
Product -> Edit Scheme -> Argument Passed On Launch
Apache再インストール時には apu-1-config に注意。
間違って /usr/local/bin, /usr/bin などに apache をインストールしてしまった場合は、apu-1-config の残骸をきっちり消す事。 以下、経緯。 apache 2.2 をインストールしていた。configure の --prefix をまちがえて --prefix=/usr/local として configure, make, make install インストールしたら、/usr/local 下に諸々がインストールされてしまった。まあ、ここまでは、よくある凡ミス。 /usr/local 以下にちらばった apache 関連のファイルを削除し、--prefix=/usr/local/www として再度 configure, make したのだが、make が通らない。コンパイル時に /usr/local/build/libtool という存在しないコマンドが使われてしまう(エラーメッセージは下の方に)。 まちがった "configure --prefix=/usr/local" の影響を受けているな、ってところまでは明白なので、make distclean して再 configure しても状況はかわらない。tarball を開き直しても状況はかわらない。 これは、先に失敗した --prefix=/usr/local の make install で作られた apu-1-config というコマンドが、PATHのかかった /usr/local/bin に残っていて、configure が、このコマンドを使い libtool の位置を特定していたのが原因だった。間違ってインストールしてしまったファイルを削除したつもりが削除しきれいてなかった、ってわけだが、configureで以前のインストールした実行ファイルを使ってしまうとは・・・ エラーメッセージはこんな感じでした。 /usr/local/build/libtool --silent --mode=compile gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/naoshi/src/httpd-2.2.19/srclib/pcre -I. -I/home/naoshi/src/httpd-2.2.19/os/unix -I/home/naoshi/src/httpd-2.2.19/server/mpm/prefork -I/home/naoshi/src/httpd-2.2.19/modules/http -I/home/naoshi/src/httpd-2.2.19/modules/filters -I/home/naoshi/src/httpd-2.2.19/modules/proxy -I/home/naoshi/src/httpd-2.2.19/include -I/home/naoshi/src/httpd-2.2.19/modules/generators -I/home/naoshi/src/httpd-2.2.19/modules/mappers -I/home/naoshi/src/httpd-2.2.19/modules/database -I/usr/local/include -I/home/naoshi/src/httpd-2.2.19/server -I/home/naoshi/src/httpd-2.2.19/modules/proxy/../generators -I/home/naoshi/src/httpd-2.2.19/modules/ssl -I/home/naoshi/src/httpd-2.2.19/modules/dav/main -c maketables.c && touch maketables.lo /bin/sh: /usr/local/build/libtool: No such file or directory
Xcode 4 でエラーが起きたとき "Issue Navigator" にエラーが表示され、ソースコードにエラーメッセージが赤字で表示されるが、いずれも表示領域が小さく、エラーが起きた具体的なシンボル名などが表示されずイラっとくる。詳細を見るために、右クリックメニューから "Reveal in Log" を選択しなければならずめんどくさい。
Behavior をいじることで、ビルドエラーがおきたときに、エラーメッセージを、メインウィンドウのタブで読みやすく表示する方法についての設定メモ。 Preferences / Behaviors の "Build fails" の項目を下記のように設定。
Xcode の左側にエラー一覧が出る。が、これだけではメッセージが読みにくいので、さらに設定・・・ デバッグ領域を隠す。エラーが起きてるから、デバッグ領域は要らないでしょう。ただ、ウィンドウやエディタサイズががちゃがちゃ動くのも見苦しいので、この機能を使わない(チェックを入れない)のもありだと思う。 Build Log という名前のタブがなければ作成し、そのタブを表示する。 この設定がないと、ビルドしていたときに開いていたタブ(たいていの場合、直近に編集していたソースファイル)のあった場所にエラーログを表示してしまう。 作成した "Build log" タブに現在のログ(つまり、失敗したビルドログ)を表示する。 |
カレンダー
カテゴリー
フリーエリア
最新CM
[02/07 @naoshi65536]
[02/07 忍]
[09/18 とおりすがり]
[06/26 ilmare]
[03/16 とおりすがり]
最新記事
(01/30)
(01/30)
(08/13)
(05/26)
(04/08)
最新TB
ブログ内検索
カウンター
アクセス解析
|