ウマ娘 2nd Anniversary

2/24 でウマ娘も2周年。

その前に前回チャンミの結果だが、ワイはグレードAで3位。
他の主要メンバーは、グレードBで共に1位。

報酬は後者の方がいいんだねえ。

ちょっと微妙な気分。

2周年

で、2周年だが、内容盛りだくさんなんだが、興味深かったのは 3000円のキャラ引き換え券の使い道。

星3キャラ引き換え券

ワイは、好みで巫女ダイヤ。

某先生は、団長キング。まあ、マイルあたりまでのチャンミを見据えると「らしいなあ」というチョイス。
バンブーとかが好きな人だから、なんかわかる。

某氏に至ってはナカヤマフェスタ(笑)

チャンミで勝ちやすいとか完全に頭の中にないらしい。

ちなみにワイ以外、クリオグリ未所持。

クリオグリいかずに好きなキャラ選ぶってのがこの人たちらしい。

ナカヤマ引いた当初はあまりのキワモノっぷりに少々後悔していたようだが、ホームに設定してからどんどんこのキャラが好きになっていったとのこと。

確かに、このセリフはかっこいい。

新シナリオ -グラマス-

まだ試行錯誤の段階のようだが、ワイ周囲の流行りのデッキ編成は

スピ3パワー1賢2

がなかば基本とかしてきた。

安定感はイマイチかもしれないが、ステ的には強い個体育成ができる。

しかし、

根性の値の1/6がスピードに、根性の値から約マイナス400し、それを1/3した値がスタミナに加算されます

という情報は本当ですかね?
だとしても、スピ1600+根性600 くらいのステ目指して方がいいような気もする。
(続く)

 

 

Karaku 2023 winter-spring

関東だと2月の後半になれば、若干、春めいた陽射しを感じることがある。

コンビニあたりにちょっと外出する程度であれば、コートは要らない。

で、そんな時に Karaku のネット広告が。

導かれて物色していると。。。

いやあ、これいいっすよねえ。

これから春先あたりまで使えそう。

商品ページはこちら…とリンク貼ろうと思ったのだが、なんかページがない。

これは売り切れちゃいましたかねえ。

(あった、ここだ)

 

arm Mac で C/C++ ライブラリを x86_64 向けにビルドする

すっかり arm 環境に移行した感のある Mac 界隈だが、なんらかの事情で Intel Mac 向けにアプリなどをビルドしたいという場合がある(案件だとね)。

アプリ自体は Xcode 上での操作でなんとかなると思うのだが、厄介なのはライブラリの類。

使いたい C/C++ のライブラリを M1/M2 Mac 上で x86_64 向けにビルドする必要が出てくる。
いわゆるクロスコンパイルというやつだ。

iOS の場合、simulator が x86_64 でしか動かないので、この手の情報はけっこうあったのだが、 MacOS 向けの情報は皆無だった。

試行錯誤したところ configure 時に以下のようなにコンパイルオプションを与えると、クロスコンパイルできるようだ。

./configure --prefix=/dir/hoge x86_64-apple-darwin64 CFLAGS='-arch x86_64 -O2 -g'

あとは make, make install でいけるっぽい。

–build オプションを使えとか、それっぽい情報はあるにはあった。
が、実行しても惜しいところまではいくんだが、なぜか最終的にはうまくいかなかった。

 

cmake で framework を生成する

この前の記事で、cmake のプロジェクトで cocoa の framework を作成するオプションを見つけたので試してみる。

framework の生成

必ずしも info.plist は必須ではないようだ。
サンプルのうち、以下のように info.plist と CODE_SIGN の部分を潰しても framework は生成される。

CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(TestFramework C)
add_libraryFr(TestFamework SHARED
 TestFramework.h
 TestFramework.c)

set_target_properties(TestFramework PROPERTIES
  FRAMEWORK TRUE
  FRAMEWORK_VERSION C
  MACOSX_FRAMEWORK_IDENTIFIER com.akiba.TestFramework
  #MACOSX_FRAMEWORK_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist
  # "current version" in semantic format in Mach-O binary file
  #VERSION 16.4.0
  # "compatibility version" in semantic format in Mach-O binary file
  #SOVERSION 1.0.0
  PUBLIC_HEADER TestFramework.h
  #XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "Developer ID Application: Taro Akiba(123xxx789)"
)

この状態で

cmake -S . -B build

としても Makefile は生成される。もちろん make で TestFramework.framework も生成される。生成するだけならば

FRAMEWORK TRUE

とするだけでいいようだ。

生成された framework を使ってみる

とりあえずお試しなので TestFramework.h と TestFramework.c は以下のような簡単なものにした。

TestFramework.h
#ifndef TESTFRAMEWORK_H
#define TESTFRAMEWORK_H

int twice(int);

#endif
TestFramework.c
#include <stdio.h>
#include "TestFramework.h"

int twice(int n) {
    return 2*n;
}

これで、cmake を走らせると確かに TestFramework.framework はできている。

次に Xcode で別のプロジェクトを作成して TestFramework.framework を取り込む。

main.m から以下のように使う。

#import <Foundation/Foundation.h>
#import <TestFramework/TestFramework.h>

int main(int argc, const char * argv[]) {
    
    NSLog(@"%2d",twice(3));
    
    return 0;
}

走らせてみると・・

予想通り 6 と表示してくれました。

成功、成功。

rpath の設定

なお、設定にもよるのだが、こうして作成されたコマンドラインプログラムを(Xcode 上ではなくて)ターミナルから実行すると

Library not loaded: @rpath

というエラーが出る時がある。
このエラーは、コンパイル時の @rpath の設定が実際に生成されたプログラムが参照すべきライブラリ(今回は TestFramework)の path と一致していない時に発生する。

その場合は、Xcode の Runpath Search Paths あたりの設定を見直してください。

ここ、指定しておかないと framework の所定の置き場所しか見に行かないようです。

正しく設定できていれば、ターミナル上からも

と Xcode 環境で走らせた時と同様の結果になります。