On Thursday, 8 March 2018 at 22:53:11 UTC, aberba wrote:
> On Thursday, 8 March 2018 at 09:35:08 UTC, Andrew Benton wrote:
>> On Thursday, 8 March 2018 at 07:54:29 UTC, Jacob Carlborg wrote:
>>> On Thursday, 8 March 2018 at 07:20:53 UTC, Radu wrote:
>>>
>>>> This guys says that vide.d works https://forum.dlang.org/thread/gikoeutmdyvolfshpqqq@forum.dlang.org
>>>
>>> Yes, it's pretty straightforward:
>>>
>>> 1. Build on Ubuntu, or some other dist
>>> 2. Statically link the whole binary with LDC, then you don't need to use Musl
>>> 3. Run it on Alpine
>>>
>>> --
>>> /Jacob Carlborg
>>
>> Looks like that works out much nicer than using alpine as the first stage right now.  I'm not sure anyone will be too upset about the extra 7MB.
>
> Building directly in alpine will simplify automated builds too.

Simple Vibe.d app talking to Redis, packed into docker containers:
https://github.com/tam4s/hello-redis

The takeaway is that I could not use Alpine as a host image, because I could not build the app statically on ubuntu.

warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

On 2018-03-11 12:10, Tamas wrote:

> Simple Vibe.d app talking to Redis, packed into docker containers:
> https://github.com/tam4s/hello-redis
> 
> The takeaway is that I could not use Alpine as a host image, because I could not build the app statically on ubuntu.
> 
> warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

It's just a warning. If you're not using "dlopen" or any of your dependencies you can just ignore the warning.

-- 
/Jacob Carlborg

On Sunday, 11 March 2018 at 11:10:09 UTC, Tamas wrote:
> On Thursday, 8 March 2018 at 22:53:11 UTC, aberba wrote:
>> On Thursday, 8 March 2018 at 09:35:08 UTC, Andrew Benton wrote:
>>> On Thursday, 8 March 2018 at 07:54:29 UTC, Jacob Carlborg wrote:
>>>> On Thursday, 8 March 2018 at 07:20:53 UTC, Radu wrote:
>>>>
>>>>> This guys says that vide.d works https://forum.dlang.org/thread/gikoeutmdyvolfshpqqq@forum.dlang.org
>>>>
>>>> Yes, it's pretty straightforward:
>>>>
>>>> 1. Build on Ubuntu, or some other dist
>>>> 2. Statically link the whole binary with LDC, then you don't need to use Musl
>>>> 3. Run it on Alpine
>>>>
>>>> --
>>>> /Jacob Carlborg
>>>
>>> Looks like that works out much nicer than using alpine as the first stage right now.  I'm not sure anyone will be too upset about the extra 7MB.
>>
>> Building directly in alpine will simplify automated builds too.
>
> Simple Vibe.d app talking to Redis, packed into docker containers:
> https://github.com/tam4s/hello-redis
>
> The takeaway is that I could not use Alpine as a host image, because I could not build the app statically on ubuntu.
>
> warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

I've put up a new binary release of ldc 1.9 for Alpine, which fixes the vibe.d issues by pulling in two upstream commits from druntime, adds druntime and Phobos as shared libraries, and includes dub and rdmd:

https://github.com/ldc-developers/ldc/releases

I tested by unpacking that release in an Alpine VPS, adding its bin/ to my path, and simply running the following:

dub fetch vibe-d
dub build vibe-d

The list of Alpine packages needed to run ldc are listed in the release notes. You can also cross-compile using the regular linux build of ldc by using ldc-build-runtime, the included tool to rebuild the stdlib for other platforms, and these instructions from the wiki:

https://wiki.dlang.org/Building_LDC_runtime_libraries#Usage_for_cross-compilation

I'm looking at adding a flag to dmd to enable building for the Musl C runtime:

https://github.com/dlang/dmd/pull/8020

While the Musl port is mostly there, it appears that yshui didn't bother porting all of druntime, so there may still be other dub packages that need other missing C declarations. However, I'm done working on this port, beyond finishing off the above pull and the druntime pull linked from the release notes, as I don't use Alpine, containers, or microservices. I simply chipped in because I have porting experience and thought I could push D for microservices a bit farther along. I'll keep putting out official builds of ldc for Alpine though, as long as there's demand for them.

If you'd like to use D in Alpine containers, now's the time to contribute to whatever else is missing.  A good idea of the current status can be found in the first post of the dmd pull linked above.

This may be a good project for the hackathon, as it's mostly polishing up a bunch of small things.

On 10/23/2017 06:02 PM, Adam Wilson wrote:
> On 10/23/17 05:08, Jacob Carlborg wrote:
>> * Database drivers for the common databases (PostgreSQL, MySQL, SQLite)
>> compatible with vibe.d
>> * Database driver abstraction on top of the above drivers, perhaps some
>> lightweight ORM library
> 
> I've been looking pretty extensively at these two items recently.
> 
> If the database drivers are compatible with Vibe.d AND we wish to provide a common abstraction layer for them (presumably via Phobos) then order for the abstraction layer to aware of the whether the driver is making a blocking or non-blocking call we must include Vibe.D in the abstraction layer.

Mysql-native is vibe.d-compatible, but also works when you have zero vibe.d dependencies (in which case it switches to Phobos's sockets instead of using Vibe's sockets.)

On 05/05/2018 02:30 PM, Nick Sabalausky (Abscissa) wrote:
> On 10/23/2017 06:02 PM, Adam Wilson wrote:
>> On 10/23/17 05:08, Jacob Carlborg wrote:
>>> * Database drivers for the common databases (PostgreSQL, MySQL, SQLite)
>>> compatible with vibe.d
>>> * Database driver abstraction on top of the above drivers, perhaps some
>>> lightweight ORM library
>>
>> I've been looking pretty extensively at these two items recently.
>>
>> If the database drivers are compatible with Vibe.d AND we wish to provide a common abstraction layer for them (presumably via Phobos) then order for the abstraction layer to aware of the whether the driver is making a blocking or non-blocking call we must include Vibe.D in the abstraction layer.
> 
> Mysql-native is vibe.d-compatible, but also works when you have zero vibe.d dependencies (in which case it switches to Phobos's sockets instead of using Vibe's sockets.)

Sorry, didn't notice this was a half-year-old thread.