First post here, would like to hear a bit more about this project.

[Chiil]

Hi all,

As this is my first post here, it might be nice to introduce myself. I
am a Arch and OSX user from the Netherlands, who is turning nuts from
using MacPorts and Fink. I work in science and do mostly model
development and data processing and visualization on my machines and
use a lot of open source software for this.

I read about your effort to bring pacman to the OSX platform and I
must say that this is one of the nicest open source initiatives for
OSX which I have seen in a long time. I think I might be interested in
joining this project, although I would like to learn a bit more about
the project before I do.

At the moment I am using both Fink and MacPorts together as I get
frustrated about the fact that none of the two is up to date with most
packages (for instance I use the KDE-X11 apps from fink and the python
related stuff from MacPorts). For me, a package manager which has
binaries for the most essential packages and some AUR like thing for
all other things seems great, as long as its binary packages are
always up to date.

However, I read on the Arch Forums that you guys are planning to stay
away from X11 related apps. For me, this would not be a nice choice,
as this still obliges me to use more than one package manager at the
same time, resulting in double packages and all other inconveniences.

Do you guys have some sort of document showing your long term plans
for this project? Although it would require a lot of work and a large
community I would love to see a decent replacement for MacPorts and
Fink.

[Tom Wambold]

On Sat, Aug 1, 2009 at 11:05 AM, Chiil<chielvanh...@gmail.com> wrote:
> As this is my first post here, it might be nice to introduce myself.

Welcome!

> For me, a package manager which has binaries for the most essential packages
> and some AUR like thing for all other things seems great, as long as its
> binary packages are always up to date.

This is kinda hard to maintain right now. I actually don't use OSX too much
anymore, but the binaries do get updated when one of us has a need for it.

> However, I read on the Arch Forums that you guys are planning to stay
> away from X11 related apps.

I'm not sure if this is an official policy. I see no issues with packaging X11
programs (I'd in fact encourage it). Actually, we do already have some X11
programs in our repositories (Wireshark, GTK, mplayer, etc). So I don't think
this is a problem.

> Do you guys have some sort of document showing your long term plans
> for this project?

I do not believe we have such a document right now. This project is mostly to
scratch our own itches, so things tend to wait until one of us has a need for
it. I'd love to put more time into this project, but right now I really can't.

> Although it would require a lot of work and a large community I would love to
> see a decent replacement for MacPorts and Fink.

If we could grow the community to that size, I'd love to replace MacPorts and
Fink, as that's why we started this!

Also, you don't really need to become a "developer" really, unless you'd like
to upload new binary packages. If you do, we can set that up for you. If not,
you can just continue to send me pull requests on Github, and I'll pull your
packages into the tree.

Thanks for your interest!
-Tom

[Chiil]

Well, I have access to both Arch (x64) and OSX system. Do you guys
have any automization to update the packages which depend on the
updated package so I could produce a whole set of up to date
binaries?

Maybe indeed a separation in core /extra / community does not make
much sense but maybe, if the repo grows larger, a testing repo might
be a good idea.

One thing that I would like to know, which tools from Apple do you
respect and do not replace with their GNU equivalents? I was surprised
to see the essential coreutil commands to be replaced by the Pacman
variant. This breaks my ls aliases for instance and I am not sure if
this is what you want.



On Aug 1, 5:26 pm, Tom Wambold <tom5...@gmail.com> wrote:

[Loic Nageleisen]

On Aug 1, 8:51 pm, Chiil <chielvanheerwaar...@gmail.com> wrote:
> Well, I have access to both Arch (x64) and OSX system. Do you guys
> have any automization to update the packages which depend on the
> updated package so I could produce a whole set of up to date
> binaries?

This very rarely needs to be done, unless there's some API change, in
which case the dependent package would certainly need to be bumped. As
the need is rare, there is none and building manually is really not as
painful as it looks. Yu might want to look at what archlinux users
propose as tools, like yaourt.

>
> Maybe indeed a separation in core /extra / community does not make
> much sense but maybe, if the repo grows larger, a testing repo might
> be a good idea.

Indeed.

>
> One thing that I would like to know, which tools from Apple do you
> respect and do not replace with their GNU equivalents? I was surprised
> to see the essential coreutil commands to be replaced by the Pacman
> variant. This breaks my ls aliases for instance and I am not sure if
> this is what you want.

only repo-add stuff needs coreutils, as a part of pacman. this
dependency is optional though as long as you don't need repo-add.
coreutils/gnu stuff may be pulled in by other packages as dependencies
may require (sometimes build-time ones only), e.g perl, for some
reason.
It might be a mistake, as we are few on the project we often just take
the PKGBUILD as needed straight from archlinux and change some paths
and stuff.

[Kevin Barry]

Things should mostly work if you change your path to have /opt/arch/bin at the end rather than the beginning. The few gotchas are that MANY build systems assumes GNU/sed or GNU/install and fail on Mac. If you keep in this in mind and set your PATH to have /opt/arch/bin at the beginning when building such packages you should be fine with /opt/arch/bin at the end of your PATH for everday use. This means your ls alias and such would not be effected.

For what it's worth, I aliased my ls to '/bin/ls -GF' as I sometimes am working on archosx and rm -rf /opt/arch but mostly like /opt/arch/bin as the default path.

[Chiil]

What is your view on which compiler to use? Are you planning to stick
to the latest GCC just as Arch itself, as this might conflict when
building software based on Aqua?

On Aug 2, 12:58 am, Kevin Barry <bar...@gmail.com> wrote:
> Things should mostly work if you change your path to have /opt/arch/bin at
> the end rather than the beginning. The few gotchas are that MANY build
> systems assumes GNU/sed or GNU/install and fail on Mac. If you keep in this
> in mind and set your PATH to have /opt/arch/bin at the beginning when
> building such packages you should be fine with /opt/arch/bin at the end of
> your PATH for everday use. This means your ls alias and such would not be
> effected.
>
> For what it's worth, I aliased my ls to '/bin/ls -GF' as I sometimes am
> working on archosx and rm -rf /opt/arch but mostly like /opt/arch/bin as the
> default path.
>
> On Sat, Aug 1, 2009 at 6:52 PM, Loic Nageleisen

> <loic.nagelei...@gmail.com>wrote:

[Loic Nageleisen]

This issue has not been raised here yet but I've got a take on it: we
_must_ use the xcode provided ones.

This allows us to use Darwin specific stuff, like
MACOSX_DEPLOYMENT_TARGET var, -arch [sic], -isysroot, -syslibroot
flags, which are mandatory to build Leopard compatible i386 binaries
on Snow Leopard. I'm in the process of documenting this, along with
building packages on SL and testing them on SL and Leo. Once this test
passes, I will move on to make it easy to build Universal (i386 +
x86_64, not ppc) packages. I've built a good deal of them, but there
are numerous pitfalls to avoid that I will document too. Lots of work
done, but lots ahead.

So, to answer your question, you should have no trouble building Aqua
packages since we have to stick with Apple's gcc anyway.

[Chiil]

Alright, this immediately raises a new issue for me... As my main use
of linux is scientific model development I am completely dependent on
gfortran, which is not provided by apple's GCC. I would prefer to use
the GNU gcc and only apply the apple ones for Aqua related tools.

Another option would be to throw gcc and g++ out of the gcc package
and only use the compilers from there which apple does not provide.
What do you think?

[Loic Nageleisen]

Interesting use case, I had similar thoughts about people needing to
cross-compile stuff, thus needing specific gcc versions. I think the
best option is to build a gcc package living in its own prefix (like /
opt/arch/opt/gcc) and thus outside any PATH or autodetection mechanism
like configure. We could then optionnally add symlinks in /opt/arch/
bin to compilers not provided by Apple like gfortran. This way we opt-
in non-conflicting stuff instead of opt-out conflicting stuff, thus
eliminating risks of missing/messing things up. Besides gcc is often
called as a front end to compilers/linkers, so it's somehow required
inside the package. What's more this allows people with special needs
to easily recompile their gcc without having to care much about
potential conflicts.

[Chiil]

Then I would personally prefer to have the standard gcc set as the
default option, as this enables us to stick as close as possible to
the Arch tree and the PKGBUILDS. For the aqua-specific apps we could
build them against Apples gcc. Do you like this approach?

For now, I have made the packages for gcc-4.4.1 which we could add to
the repo. This should work perfectly for every package except those
which require Aqua. Do we need Apple's gcc for X11 stuff on OSX?

[Loic Nageleisen]

Is your problem only to have the custom gcc by default when used
locally? If so, it is only a slight usability problem. As Kevin said,
this is just a matter of PATH ordering.

When you say "for the aqua-specific apps we could build them against
Apples gcc" and "This should work perfectly for every package except
those which require Aqua", in fact this does not quite work. It might
work locally on your machine, but as soon as you think in terms of
binary distribution it stops working. For example, compiling with a
custom 'standard' gcc version will inevitably link against some system
libraries (e.g libcrt), which will, if built on 10.6, produce non-
working packages on 10.5 (if it even compiles at all). Therefore it
would be mandatory for package builders to build packages targetting
one minimum OS version on the matching OS. As we build binary
packages, we have to make sure they will run on the OS versions we
chose to support. So if we target 10.5 at a minimum we would have to
build all packages on 10.5 and can't build them on 10.6, ever, until
we drop support for 10.5. And I'm only scratching upon the surface of
obvious stuff (fundamental lib linking, header includes) when building
for one arch, as we would hit even more issues when building universal
32+64 binaries.

Hopefully, Apple has tackled and solved all of those (known and
unknown to us) issues. See for example http://developer.apple.com/technotes/tn2002/tn2064.html

That's why we have to use Apple's gcc to build packages we distribute,
whether or not we provide our own gcc package. Believe me, I've hit
many of those issues, like crashes, leaks, infinite loops due to stack/
heap corruption and so on since I began testing on 10.6, either
because I goofed up when building some libs or the build system
provided by upstream did not pick {C,LD}FLAGS correctly. It's not
pretty, and each time I tracked it down to this kind of build issues.
By leveraging Apple's gcc features we really ease our task, and
actually make it work. As a bonus, if PPC folks ever want to join the
train, this will be a treat for them.

The core goal of this project is to empower OSX with the Arch
philosophy, and although we can obviously benefit from some synergy
due to package management and unix foundation, we just can't stick to
the ArchLinux (which I assume is what you meant by 'Arch') tree. This
has been made especially obvious to me when testing on Snow Leopard
(even if we build only for i386).

As I said before, all of this is true for building packages to be
distributed, not using gcc locally (like the way you use gfortran), so
we just have to make sure that makepkg use Apple's gcc and configure
stuff never ever pick our gcc stuff (so as not to depend on gcc
package at runtime).

By the way, and somehow unrelated, could you make your gcc package
able to target both i386 and x86_64 (i.e cross-compiling)?

[Chiil]

Alright, I understand the point. Do you want an additional package
creating a cross compiler to produce 64 bits packages or do you want
to enable the compiler to create 64bits packages?

On Aug 2, 10:54 pm, Loic Nageleisen <loic.nagelei...@gmail.com> wrote:
> Is your problem only to have the custom gcc by default when used
> locally? If so, it is only a slight usability problem. As Kevin said,
> this is just a matter of PATH ordering.
>
> When you say "for the aqua-specific apps we could build them against
> Apples gcc" and "This should work perfectly for every package except
> those which require Aqua", in fact this does not quite work. It might
> work locally on your machine, but as soon as you think in terms of
> binary distribution it stops working. For example, compiling with a
> custom 'standard' gcc version will inevitably link against some system
> libraries (e.g libcrt), which will, if built on 10.6, produce non-
> working packages on 10.5 (if it even compiles at all). Therefore it
> would be mandatory for package builders to build packages targetting
> one minimum OS version on the matching OS. As we build binary
> packages, we have to make sure they will run on the OS versions we
> chose to support. So if we target 10.5 at a minimum we would have to
> build all packages on 10.5 and can't build them on 10.6, ever, until
> we drop support for 10.5. And I'm only scratching upon the surface of
> obvious stuff (fundamental lib linking, header includes) when building
> for one arch, as we would hit even more issues when building universal
> 32+64 binaries.
>
> Hopefully, Apple has tackled and solved all of those (known and

> unknown to us) issues. See for examplehttp://developer.apple.com/technotes/tn2002/tn2064.html

[Loic Nageleisen]

The compiler provided by a single package should be able to cross-
compile to i386 and x86_64 targets, regardless of it is itself a 32bit
or 64bit host binary (32-bit for now, but thinking for the future), so
that would be your second option.

Still, the first one is interesting as an example of how I think we
could package gcc "add-on" packages for more exotic cross-compilers
targetting, say, arm.

> > > > > > > > > > > > For me, a package manager which has...
>
> read more »

[Chiil]

Alright, with this you just mean to be able to run gcc with the -m64
flag? I don't have much experience with cross-compiling stuff. For
that reason I am not going to create cross compiler packages now. I
have added a suffix to the gnu compilers (-gnu-44) to not conflict
with the apple ones.

> > > > > > > > > > coreutils/gnu...
>
> read more »

[Loic Nageleisen]

The suffix idea is a good one, although I would have named it with a
dot (-gnu-4.4) to be in line with apple's ones (named gcc-4.0 and
gcc-4.2).

Thanks for your work and input on that part.

For reference, cross-compiling works this way:
- ./configure gcc to output binaries for a target platform (with the --
target= flag)
- compile gcc with a gcc outputting binaries for a host platform
and you will end up with a specific gcc binary e.g x86_64-darwin-gcc
that is istelf a Mach-O i386 but outputs Mach-O x86_64 binaries.

So in true cross-compiling you actually end up with two distinct
compilers.

Hopefully on x86 targets we have:

$ gcc --target-help
...
-m32 Generate 32bit i386 code
-m64 Generate 64bit x86-64 code
...

So in our specific case we really need only one compiler, since we
target the same binary/libc platform (Mach-O darwin) and merely use a
"machine option" flag. Therefore I think -m32/64 is sufficient.

Note that we also need binutils to be configured correctly too.

Those two pages might help in the future:
http://linux.bytesex.org/cross-compiler.html
http://www.unix.com/linux/95143-gcc-cross-compiler-x86_64-elf.html

> > > > > > > > > > > > be a good idea....
>
> read more »

[Chiil]

Alright, I changed the suffix. How about the binutils? Apple's cctools
have clearly different behaviour than the GNU bintools. I removed the
binutils dependency on purpose to use Apple's tools. Do I need to
compile the CC tools for a different target, rather than the binutils?
Then I can give a try.

On Aug 3, 2:32 pm, Loic Nageleisen <loic.nagelei...@gmail.com> wrote:
> The suffix idea is a good one, although I would have named it with a
> dot (-gnu-4.4) to be in line with apple's ones (named gcc-4.0 and
> gcc-4.2).
>
> Thanks for your work and input on that part.
>
> For reference, cross-compiling works this way:
> - ./configure gcc to output binaries for a target platform (with the --
> target= flag)
> - compile gcc with a gcc outputting binaries for a host platform
> and you will end up with a specific gcc binary e.g x86_64-darwin-gcc
> that is istelf a Mach-O i386 but outputs Mach-O x86_64 binaries.
>
> So in true cross-compiling you actually end up with two distinct
> compilers.
>
> Hopefully on x86 targets we have:
>
> $ gcc --target-help
> ...
> -m32                        Generate 32bit i386 code
> -m64                        Generate 64bit x86-64 code
> ...
>
> So in our specific case we really need only one compiler, since we
> target the same binary/libc platform (Mach-O darwin) and merely use a
> "machine option" flag. Therefore I think -m32/64 is sufficient.
>
> Note that we also need binutils to be configured correctly too.
>

> Those two pages might help in the future:http://linux.bytesex.org/cross-compiler.htmlhttp://www.unix.com/linux/95143-gcc-cross-compiler-x86_64-elf.html

> > > > > > > > > > > building such packages you should...
>
> read more »

[Loic Nageleisen]

This sounds great as is, let's use Apple's provided cctools. Binutils
would be needed only for people wanting to do real cross-compiling,
and I mentioned them for completeness.

> > Those two pages might help in the future:http://linux.bytesex.org/cross-compiler.htmlhttp://www.unix.com/linux...

> > > > > > > > > > > What is your view on which compiler to use?...
>
> read more »

[Chiil]

Great. I will push an updated gcc, gcc-libs and mpich2 (using gcc
4.4.1) to my forked repo on github later today. I am going through my
MacPorts list and port everything to PKGBUILDS bit by bit. I will
start on GIMP and Inkscape soon, but I expect more trouble here.

I noticed, by the way, that if you do --target-help on any gcc
compiler on OSX you always get an error message in the end. I first
noticed this testing my compilation of gcc, but it also occurs using
apple's gcc.

FATAL:/usr/bin/../libexec/gcc/darwin/i386/as: I don't understand '-'
flag!