On Wednesday, 12 February 2014 at 23:18:07 UTC, Sönke Ludwig wrote:
> Am 12.02.2014 19:12, schrieb Sönke Ludwig:
>> Am 12.02.2014 16:40, schrieb Jordi Sayol:
>>> El 12/02/14 09:53, Sönke Ludwig ha escrit:
>>>> The binaries can be found on http://code.dlang.org/download ("Latest
>>>> preview").
>>>
>>> On Debian 7.4 64-bit:
>>>
>>> $ dub
>>> dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
>>> (required by dub)
>>>
>>>
>>> No problem on Debian 7.4 32-bit.
>>>
>>
>> I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit,
>> hopefully that works...
>
> Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.

I just tried to run dub on Amazon ami linux. Although it runs it prints:
dub: /usr/lib64/libcurl.so.4: no version information available (required by dub)

Is that a problem ? WOuld it be fixed if I built dub myself there ?

Nice to see the dependencies not having to be compiled over and over again. One thing though: It seems dependencies are compiled with -m32 and my source with -m64, meaning they have different object formats in Windows, and the linker chokes.

I just tried the Linux x86_64 executable on Fedora 20, and it works except for:

dub: /lib64/libcurl.so.4: no version information available (required by
dub)

I am not entirely sure why it doesn't find:

/usr/lib64/libcurl.so.4
/usr/lib/libcurl.so.4

which are most definitely present.

I also tried the OSX executable on a Mavericks machine and it works fine, except…

… I have a single filestore and thus a single ~/.dub but the compilation products of dub are not in architecture dependent locations so I cannot work with OSX and Linux at the same time.

There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy, currently I seem to have to manually search all the dependencies and clean up. In fact, is there a clean command to dub to clean the project and the ~/.dub?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Am 13.02.2014 10:28, schrieb Russel Winder:
> On Thu, 2014-02-13 at 00:18 +0100, Sönke Ludwig wrote:
> […]
>> Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.
>
> I missed earlier activity, but just downloaded the Linux x86_64
> 0.9.21-rc3 and it appears to work fine on Debian Sid (Unstable). Except…
>
> …I have no idea what to put in the package.json file to get rid of this
> problem:
>
>          source/main.d(27): Error: need -Jpath switch to import text file
>          VERSION
>
> http://code.dlang.org/package-format doesn't mention this option.
>
> -J. is all I need given my SCons build of this same project.
>
>

That's the "stringImportPaths" field which corresponds to -J, there should probably be a small note to which DMD flag each field corresponds (if applicable, of course).

Am 13.02.2014 11:55, schrieb "Casper Færgemand" <shorttail@hotmail.com>":
> Nice to see the dependencies not having to be compiled over and over
> again. One thing though: It seems dependencies are compiled with -m32
> and my source with -m64, meaning they have different object formats in
> Windows, and the linker chokes.

Good catch. I'll look into that.

Am 13.02.2014 11:39, schrieb extrawurst:
> On Wednesday, 12 February 2014 at 23:18:07 UTC, Sönke Ludwig wrote:
>> Am 12.02.2014 19:12, schrieb Sönke Ludwig:
>>> Am 12.02.2014 16:40, schrieb Jordi Sayol:
>>>> El 12/02/14 09:53, Sönke Ludwig ha escrit:
>>>>> The binaries can be found on http://code.dlang.org/download ("Latest
>>>>> preview").
>>>>
>>>> On Debian 7.4 64-bit:
>>>>
>>>> $ dub
>>>> dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
>>>> (required by dub)
>>>>
>>>>
>>>> No problem on Debian 7.4 32-bit.
>>>>
>>>
>>> I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit,
>>> hopefully that works...
>>
>> Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.
>
> I just tried to run dub on Amazon ami linux. Although it runs it prints:
> dub: /usr/lib64/libcurl.so.4: no version information available (required
> by dub)
>
> Is that a problem ? WOuld it be fixed if I built dub myself there ?

libcurl is a dependency of Phobos, so I'm actually not sure. Maybe it's necessary to rebuild Phobos, too.

Am 13.02.2014 12:40, schrieb Russel Winder:
> I just tried the Linux x86_64 executable on Fedora 20, and it works
> except for:
>
> dub: /lib64/libcurl.so.4: no version information available (required by
> dub)
>
> I am not entirely sure why it doesn't find:
>
> /usr/lib64/libcurl.so.4
> /usr/lib/libcurl.so.4
>
> which are most definitely present.

Looks like this is more common than it seemed. I can try to compile on the older Ubuntu 11.10 VM, or, if someone can donate an RPM recipe and the necessary commands, I could also set up a Fedora VM and provide a proper RPM package.

>
> I also tried the OSX executable on a Mavericks machine and it works
> fine, except…
>
> … I have a single filestore and thus a single ~/.dub but the compilation
> products of dub are not in architecture dependent locations so I cannot
> work with OSX and Linux at the same time.

I'll add the OS to the generated folder names, I didn't think of this case when defining the format of those and wanted to keep them as short as possible.

>
> There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy,
> currently I seem to have to manually search all the dependencies and
> clean up. In fact, is there a clean command to dub to clean the project
> and the ~/.dub?
>

There is an enhancement request for this, but it hasn't been implemented, yet. What is there, though, is the --force switch for forcing a rebuild.

On Thursday, 13 February 2014 at 11:40:56 UTC, Russel Winder wrote:
> I just tried the Linux x86_64 executable on Fedora 20, and it works
> except for:
>
> dub: /lib64/libcurl.so.4: no version information available (required by
> dub)
>
> I am not entirely sure why it doesn't find:
>
> /usr/lib64/libcurl.so.4
> /usr/lib/libcurl.so.4
>
> which are most definitely present.
>
> I also tried the OSX executable on a Mavericks machine and it works
> fine, except…
>
> … I have a single filestore and thus a single ~/.dub but the compilation
> products of dub are not in architecture dependent locations so I cannot
> work with OSX and Linux at the same time.
>
> There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy,
> currently I seem to have to manually search all the dependencies and
> clean up. In fact, is there a clean command to dub to clean the project
> and the ~/.dub?

https://github.com/rejectedsoftware/dub/issues/134

In the mean time I would just delete the whole ~/.dub folder every time you change OS.

Am 13.02.2014 11:55, schrieb "Casper Færgemand" <shorttail@hotmail.com>":
> It seems dependencies are compiled with -m32
> and my source with -m64, meaning they have different object formats in
> Windows, and the linker chokes.

After some testing, all I can get is multiple -m64 switches, which isn't pretty, but shouldn't do any harm. Do you compile with --arch=x86_64 or did you manually add the -m64 flag somewhere? The latter would explain the issue, as only -version= flags are inherited downwards to the dependencies (except for build type flags).

On Thursday, 13 February 2014 at 12:57:02 UTC, Sönke Ludwig wrote:
> After some testing, all I can get is multiple -m64 switches, which isn't pretty, but shouldn't do any harm. Do you compile with --arch=x86_64 or did you manually add the -m64 flag somewhere? The latter would explain the issue, as only -version= flags are inherited downwards to the dependencies (except for build type flags).

Herp derp, didn't know about that one. It works now.
Is it possible to specify in package.json?