A little while ago, there was a discussion about where to put the 32-bit phobos library in the DMD archive. It was finally decided that the 32-bit version would  go to a lib32 directory, and the 64-bit one in a lib64 directory.

That's all fine for Linux, but I brought to the discussion that on OS X the standard way is to create a universal binary which includes both architectures in one file. That's how libraries are packaged on OS X. But I was told, that this didn't concern OS X (yet) as the 64-bit port was (for now) Linux-only. Valid point.

But now, I see that in the archive the OS X library has been moved to a lib32 directory. Was this intentional or is it an oversight? Is the plan to do things as they're done on Linux and not have a universal multi-architecture binary?

Currently D for Xcode is broken by this change and I'm looking at the best way to fix it. In the sort term I might just change the path to point to the lib32 directory instead of simply "lib". But the current approach which is to put a symbolic link in /usr/local/lib pointing to libphobos2.a won't work anymore if the binary for the two architectures are kept in separate files...

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 3/26/2011 1:26 PM, Michel Fortin wrote:
> A little while ago, there was a discussion about where to put the 32-bit phobos library in the DMD archive. It was finally decided that the 32-bit version would  go to a lib32 directory, and the 64-bit one in a lib64 directory.
>
> That's all fine for Linux, but I brought to the discussion that on OS X the standard way is to create a universal binary which includes both architectures in one file. That's how libraries are packaged on OS X. But I was told, that this didn't concern OS X (yet) as the 64-bit port was (for now) Linux-only. Valid point.
>
> But now, I see that in the archive the OS X library has been moved to a lib32 directory. Was this intentional or is it an oversight? Is the plan to do things as they're done on Linux and not have a universal multi-architecture binary?
>
> Currently D for Xcode is broken by this change and I'm looking at the best way to fix it. In the sort term I might just change the path to point to the lib32 directory instead of simply "lib". But the current approach which is to put a symbolic link in /usr/local/lib pointing to libphobos2.a won't work anymore if the binary for the two architectures are kept in separate files...
>

I don't know what the right answer is.

I think the right approach is to build universal binaries and keep them in the folder named "lib".

-- 
/Jacob Carlborg

On 27 mar 2011, at 01:35, Walter Bright wrote:

> 
> 
> On 3/26/2011 1:26 PM, Michel Fortin wrote:
>> A little while ago, there was a discussion about where to put the 32-bit phobos library in the DMD archive. It was finally decided that the 32-bit version would  go to a lib32 directory, and the 64-bit one in a lib64 directory.
>> 
>> That's all fine for Linux, but I brought to the discussion that on OS X the standard way is to create a universal binary which includes both architectures in one file. That's how libraries are packaged on OS X. But I was told, that this didn't concern OS X (yet) as the 64-bit port was (for now) Linux-only. Valid point.
>> 
>> But now, I see that in the archive the OS X library has been moved to a lib32 directory. Was this intentional or is it an oversight? Is the plan to do things as they're done on Linux and not have a universal multi-architecture binary?
>> 
>> Currently D for Xcode is broken by this change and I'm looking at the best way to fix it. In the sort term I might just change the path to point to the lib32 directory instead of simply "lib". But the current approach which is to put a symbolic link in /usr/local/lib pointing to libphobos2.a won't work anymore if the binary for the two architectures are kept in separate files...
>> 
> 
> I don't know what the right answer is.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Le 2011-03-26 ? 20:35, Walter Bright a ?crit :

> On 3/26/2011 1:26 PM, Michel Fortin wrote:
>> A little while ago, there was a discussion about where to put the 32-bit phobos library in the DMD archive. It was finally decided that the 32-bit version would  go to a lib32 directory, and the 64-bit one in a lib64 directory.
>> 
>> That's all fine for Linux, but I brought to the discussion that on OS X the standard way is to create a universal binary which includes both architectures in one file. That's how libraries are packaged on OS X. But I was told, that this didn't concern OS X (yet) as the 64-bit port was (for now) Linux-only. Valid point.
>> 
>> But now, I see that in the archive the OS X library has been moved to a lib32 directory. Was this intentional or is it an oversight? Is the plan to do things as they're done on Linux and not have a universal multi-architecture binary?
>> 
>> Currently D for Xcode is broken by this change and I'm looking at the best way to fix it. In the sort term I might just change the path to point to the lib32 directory instead of simply "lib". But the current approach which is to put a symbolic link in /usr/local/lib pointing to libphobos2.a won't work anymore if the binary for the two architectures are kept in separate files...
> 
> I don't know what the right answer is.

The best thing would be to have a single multi-architecture library in a "lib" folder. Which would mean going back to "lib" instead of "lib32".

And when the 64-bit version appears, you can easily combine the two architectures into a single library file using the "lipo" command and let the linker handle things from there on.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 3/27/2011 6:41 AM, Michel Fortin wrote:
> Le 2011-03-26 ? 20:35, Walter Bright a ?crit :
>
>> On 3/26/2011 1:26 PM, Michel Fortin wrote:
>>> A little while ago, there was a discussion about where to put the 32-bit phobos library in the DMD archive. It was finally decided that the 32-bit version would  go to a lib32 directory, and the 64-bit one in a lib64 directory.
>>>
>>> That's all fine for Linux, but I brought to the discussion that on OS X the standard way is to create a universal binary which includes both architectures in one file. That's how libraries are packaged on OS X. But I was told, that this didn't concern OS X (yet) as the 64-bit port was (for now) Linux-only. Valid point.
>>>
>>> But now, I see that in the archive the OS X library has been moved to a lib32 directory. Was this intentional or is it an oversight? Is the plan to do things as they're done on Linux and not have a universal multi-architecture binary?
>>>
>>> Currently D for Xcode is broken by this change and I'm looking at the best way to fix it. In the sort term I might just change the path to point to the lib32 directory instead of simply "lib". But the current approach which is to put a symbolic link in /usr/local/lib pointing to libphobos2.a won't work anymore if the binary for the two architectures are kept in separate files...
>> I don't know what the right answer is.
> The best thing would be to have a single multi-architecture library in a "lib" folder. Which would mean going back to "lib" instead of "lib32".
>
> And when the 64-bit version appears, you can easily combine the two architectures into a single library file using the "lipo" command and let the linker handle things from there on.

There's a conflict with the "mac way" and the "unix way". I'll have to agree with Michel that on the mac we should do it the mac way.

Le 2011-03-28 ? 1:38, Walter Bright a ?crit :

> There's a conflict with the "mac way" and the "unix way". I'll have to agree with Michel that on the mac we should do it the mac way.

By this, do I understand that the next release will return to using "lib" instead of "lib32". If so, that's great. Thanks.

Here's what I'll do on my side. I'll make an exception in my installer so that if it downloads DMD 2.052 it automatically adds a symlink at "osx/lib" pointing to "osx/lib32". This will make things work for this release. The downside is that it won't work if the user installs DMD manually by unpacking the archive at the right place, but if the next DMD release return to using "lib" the problem will be limited to manual downloads of DMD version 2.052, which shouldn't be too bad.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On Mon, Mar 28, 2011 at 8:04 AM, Michel Fortin <michel.fortin at michelf.com> wrote:

> Here's what I'll do on my side. I'll make an exception in my installer so that if it downloads DMD 2.052 it automatically adds a symlink at "osx/lib" pointing to "osx/lib32". This will make things work for this release. The downside is that it won't work if the user installs DMD manually by unpacking the archive at the right place, but if the next DMD release return to using "lib" the problem will be limited to manual downloads of DMD version 2.052, which shouldn't be too bad.

Might I suggest you just test for the existence of lib32. There have been a number of folder restructuring in the past, and this is what I've done to keep it compatibly with older zips (not that I actually tested them).

Le 2011-03-28 ? 20:47, Jesse Phillips a ?crit :

> On Mon, Mar 28, 2011 at 8:04 AM, Michel Fortin <michel.fortin at michelf.com> wrote:
> 
>> Here's what I'll do on my side. I'll make an exception in my installer so that if it downloads DMD 2.052 it automatically adds a symlink at "osx/lib" pointing to "osx/lib32". This will make things work for this release. The downside is that it won't work if the user installs DMD manually by unpacking the archive at the right place, but if the next DMD release return to using "lib" the problem will be limited to manual downloads of DMD version 2.052, which shouldn't be too bad.
> 
> Might I suggest you just test for the existence of lib32. There have been a number of folder restructuring in the past, and this is what I've done to keep it compatibly with older zips (not that I actually tested them).

That's a fairly good suggestion. It makes things more robust, and it's exactly what I made my installer do in the end (see D for Xcode, version 1.2.2 released today).

But I still hope the "lib32" folder goes back to its original name "lib" soon so unpacking the archive manually will work too with the symlinks installed in /usr/local.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/