Tried OpenPKG on Mac OS X and ran into some minor
build issues with using static libraries on Darwin...
1) miniperl was using a dynamic libperl.dylib by default,
and this didn't work when running from /tmp/openpkg
2) openssl does not work on darwin when using static libs,
due to a hack
Bill Campbell wrote:
Tried OpenPKG on Mac OS X and ran into some minor
build issues with using static libraries on Darwin...
I've got a fair number of packages running on PowerPC OS X.
I saw that it was working for Mac OS X 10.3, so I thought I'd try it...
I've found that most packages
With those two issues patched, it then bootstrapped just
fine on Mac OS X 10.4.9 (tested on PowerPC and on Intel)
[...]
Now onwards to test some actual packages, but it looks good.
Will let you know if I find anything else, or just ask...
Tested building some packages now, and that's where
What's the easiest way to customize the
generated platform names that OpenPKG uses ?
Currently it says e.g. i386-any-darwin8.9.1,
while the Apple tools use i686-apple-darwin8
`uname -srp` says Darwin 8.9.1 i386 so it is
technically right, but the kernel/Mac OS minor
version probably shouldn't
First, a small addition to the openssl.patch for test:
http://www.algonet.se/~afb/openpkg/openssl-addition.diff
(originally did the same thing for apps for the bootstrap)
However, the *reason* for the workaround is the fact that
since OpenPKG does not provide a shared OpenSSL library,
Darwin
Ralf S. Engelschall wrote:
Currently it says e.g. i386-any-darwin8.9.1,
while the Apple tools use i686-apple-darwin8
You talk about prefix/etc/openpkg/platform, I guess. This is a
generated file just to make RPM happy. The any is inserted as
OpenPKG itself doesn't use the
Ralf S. Engelschall wrote:
However, the *reason* for the workaround is the fact that
since OpenPKG does not provide a shared OpenSSL library,
Darwin ld(1) will try to use the /usr/lib variant instead...
So this will affect everything else using OpenSSL as well.
The real solution would be
I don't know of any linker option to have it look for static libs
(other than explicitly listing them by name), but either a wrapper
to the binary or even patching the source of the binary is doable.
Reading through the source code I realize I didn't look *that* hard:
-search_paths_first
I did approach 1) for OpenSSL and approach 3) for Apache,
and then the pitch succeeded* in running apache+lynx. :-)
Hmm, almost forgot to mention that I did have to change
the default apache configuration before it would start up:
OpenPKG: start: apache:FAILED
openpkg:rc:WARNING:
Ralf S. Engelschall wrote:
Might a be a space or two too many for Mac OS X, but otherwise
it is looking good I think ? (OpenDarwin is unfortunately dead)
Ops, yes. Seems like we have to strip spaces somewhere. Can you quickly
retry again with the version appended? There I tried to get rid
Ralf S. Engelschall wrote:
My bad, it was a tab character rather than spaces:
Ah, a tab! This explains why even the old version failed. Ok, please
once again and hopefully the last time I have to bother you with this
nasty detection. Please retry with the appended version.
Numbers works
Ralf S. Engelschall wrote:
It should be:
concise system product: Mac OS X 10
regular system product: Mac OS X 10.3
verbose system product: Apple Mac OS X 10.3.9
And the technology should be:
concise system technology: Darwin 7
regular system
Ralf S. Engelschall wrote:
And need to provide fake binutils/gcc packages, with /usr symlinks.
(so that dependencies and such work, otherwise it'll try to install)
/openpkg/bin/cc - /usr/bin/cc
/openpkg/bin/gcc - /usr/bin/gcc
This can be provided by openpkg-import.
Will do that, then:
This can be provided by openpkg-import.
Will do that, then: use openpkg-import to replace binutils and gcc.
One little problem is that the binutils and cctools differ in content,
so
the following programs are missing: addr2line, objcopy, objdump,
readelf
I fixed the missing symlink target
Ralf S. Engelschall wrote:
However, this still did not work because OpenPKG will fail to locate
the real compiler e.g. i686-apple-darwin8-gcc-4.0.1 (from /usr/bin),
but only find the gcc-4.0 driver front-end... (symlinked from cc)
So either I need to bring some more symlinks in, or do it
Ralf S. Engelschall wrote:
Oh, I see. Ok, I've now improved the wrapper scripts. Please manually
remove prefix/libexec/openpkg/override/{cc,gcc} and upgrade to the
latest bootstrap version as of today. Then if -c or -E is present
on the compiler command line the -Wl,-search_paths_first should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
compiling with static libs for darwin breaks during compile...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19176
libgcc_s is required for correct running in terms of exceptions
An interesting comment is:
i686-darwin is not supported in any
Ralf S. Engelschall wrote:
I've now tried to build our gcc package (GCC 4.2.0). t starts just
Ifine and compiles lots of things, but then it unfortunately fails
[...]
| strip -o libgcc_s.10.4.dylib_T${mlib} \
| -s
Ralf S. Engelschall wrote:
2) by default it tries to use GNU/FSF gcc. This is not
100% binary compatible with Apple's gcc as far as I
know and might lead to some subtle libgcc/libstdc++
problems later on ? So will switch, to gcc-5363.
I've now tried to build our gcc package (GCC
Ralf S. Engelschall wrote:
Seems like lipo is some sort of a tool for the Universal Binaries
stuff of Mac OS X
Yup. The name made more sense when they were called fat binaries...
http://developer.apple.com/documentation/Darwin/Reference/ManPages/
man1/lipo.1.html
It's part of cctools.
Some software needed patching, in order to build:
1) extern inline is broken, with the Apple GCC
this breaks most of GTK+, but also GNU tar...
I hacked around the issue, just to make the bootstrap work OK:
http://www.algonet.se/~afb/openpkg/tar-1.19-apple_nocode.patch
2) Bash doesn't work
21 matches
Mail list logo
