unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Reducing LLVM closure size
@ 2020-06-12  9:06 Pierre Neidhardt
  2020-06-12 12:01 ` Julien Lepiller
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-12  9:06 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Since LLVM is all over the place, _multiple_ versions of LLVM inevitably
end up in anyone's graph.

Can we reduce its closure size?

--8<---------------cut here---------------start------------->8---
> guix size llvm
store item                                                       total    self
/gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0            210.8   139.3  66.1%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    36.7  17.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    32.6  15.5%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16       1.6     1.6   0.8%
/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11             71.2     0.2   0.1%
/gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3              71.2     0.2   0.1%
total: 210.8 MiB
--8<---------------cut here---------------end--------------->8---

Let's look at what Arch Linux does:

- https://www.archlinux.org/packages/extra/x86_64/llvm/
- https://www.archlinux.org/packages/extra/x86_64/llvm-libs/
- https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/llvm

For the first 2 links, click on
"View the file list for ..." link at the bottom to display the file
list.

"bin" and "include" occupy some 35 MiB.  First thing we can do is split

- either move the libs to a "lib" output,
- or move the "bin" and "include" folder to a new output.

The second approach has the benefit of being less disruptive for dependents.

Now if we look at the PKGBUILD, there are some interesting compilation
flags.  If we remove

  "-DBUILD_SHARED_LIBS:BOOL=TRUE"

and add

  "-DLLVM_BUILD_LLVM_DYLIB=ON"
  "-DLLVM_LINK_LLVM_DYLIB=ON"

it will produce a single libLLVM-10.so library.  This reduces the "lib"
folder size from 107 MiB to 90 MiB.

All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
package (and 210 MiB from its closure).

This would need a bit of testing since LLVM has many versions and many
dependents (a change to llvm-3 rebuilds 1000+ dependents).

By the way, this looks like a bug:

--8<---------------cut here---------------start------------->8---
> guix refresh -l llvm
Building the following package would ensure 3 dependent packages are rebuilt: clang-toolchain@10.0.0
--8<---------------cut here---------------end--------------->8---

Why is only 1 package displayed?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12  9:06 Reducing LLVM closure size Pierre Neidhardt
@ 2020-06-12 12:01 ` Julien Lepiller
  2020-06-12 12:09   ` Oliver Propst
  2020-06-12 13:19   ` Pierre Neidhardt
  2020-06-13 12:28 ` Arun Isaac
  2020-06-16  9:22 ` Ludovic Courtès
  2 siblings, 2 replies; 16+ messages in thread
From: Julien Lepiller @ 2020-06-12 12:01 UTC (permalink / raw)
  To: guix-devel, Pierre Neidhardt

Le 12 juin 2020 05:06:32 GMT-04:00, Pierre Neidhardt <mail@ambrevar.xyz> a écrit : 
>
>By the way, this looks like a bug:
>
>--8<---------------cut here---------------start------------->8---
>> guix refresh -l llvm
>Building the following package would ensure 3 dependent packages are
>rebuilt: clang-toolchain@10.0.0
>--8<---------------cut here---------------end--------------->8---
>
>Why is only 1 package displayed?

Because these are the dependants for llvm@10, but the default llvm is llvm@9:

guix refresh -l llvm@9
Building the following 1180 packages would ensure 2092 lependent packages are rebuilt: …

That's not on latest master, so your numbers can vary a bit.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12 12:01 ` Julien Lepiller
@ 2020-06-12 12:09   ` Oliver Propst
  2020-06-12 13:19   ` Pierre Neidhardt
  1 sibling, 0 replies; 16+ messages in thread
From: Oliver Propst @ 2020-06-12 12:09 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Well I think regardless that Pierre's efforts are very good and should
be encouraged.


On Fri, Jun 12, 2020 at 2:02 PM Julien Lepiller <julien@lepiller.eu> wrote:

> Le 12 juin 2020 05:06:32 GMT-04:00, Pierre Neidhardt <mail@ambrevar.xyz>
> a écrit :
> >
> >By the way, this looks like a bug:
> >
> >--8<---------------cut here---------------start------------->8---
> >> guix refresh -l llvm
> >Building the following package would ensure 3 dependent packages are
> >rebuilt: clang-toolchain@10.0.0
> >--8<---------------cut here---------------end--------------->8---
> >
> >Why is only 1 package displayed?
>
> Because these are the dependants for llvm@10, but the default llvm is
> llvm@9:
>
> guix refresh -l llvm@9
> Building the following 1180 packages would ensure 2092 lependent packages
> are rebuilt: …
>
> That's not on latest master, so your numbers can vary a bit.
>
>

-- 
-mvh Oliver Propst

[-- Attachment #2: Type: text/html, Size: 1442 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12 12:01 ` Julien Lepiller
  2020-06-12 12:09   ` Oliver Propst
@ 2020-06-12 13:19   ` Pierre Neidhardt
  2020-06-12 13:34     ` Julien Lepiller
  1 sibling, 1 reply; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-12 13:19 UTC (permalink / raw)
  To: Julien Lepiller, guix-devel

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Julien Lepiller <julien@lepiller.eu> writes:

>>By the way, this looks like a bug:
>>
>>--8<---------------cut here---------------start------------->8---
>>> guix refresh -l llvm
>>Building the following package would ensure 3 dependent packages are
>>rebuilt: clang-toolchain@10.0.0
>>--8<---------------cut here---------------end--------------->8---
>>
>>Why is only 1 package displayed?
>
> Because these are the dependants for llvm@10, but the default llvm is llvm@9:
>
> guix refresh -l llvm@9
> Building the following 1180 packages would ensure 2092 lependent packages are rebuilt: …

This does not explain why it says "3 dependent packages" but lists only
one! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12 13:19   ` Pierre Neidhardt
@ 2020-06-12 13:34     ` Julien Lepiller
  2020-06-12 14:13       ` Pierre Neidhardt
  0 siblings, 1 reply; 16+ messages in thread
From: Julien Lepiller @ 2020-06-12 13:34 UTC (permalink / raw)
  To: Pierre Neidhardt, guix-devel

Le 12 juin 2020 09:19:48 GMT-04:00, Pierre Neidhardt <mail@ambrevar.xyz> a écrit :
>Julien Lepiller <julien@lepiller.eu> writes:
>
>>>By the way, this looks like a bug:
>>>
>>>--8<---------------cut here---------------start------------->8---
>>>> guix refresh -l llvm
>>>Building the following package would ensure 3 dependent packages are
>>>rebuilt: clang-toolchain@10.0.0
>>>--8<---------------cut here---------------end--------------->8---
>>>
>>>Why is only 1 package displayed?
>>
>> Because these are the dependants for llvm@10, but the default llvm is
>llvm@9:
>>
>> guix refresh -l llvm@9
>> Building the following 1180 packages would ensure 2092 lependent
>packages are rebuilt: …
>
>This does not explain why it says "3 dependent packages" but lists only
>one! :)

Because building this one will also rebuild the other two, re-read the sentence carefully :)

llvm -> clang -> clang-toolchain



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12 13:34     ` Julien Lepiller
@ 2020-06-12 14:13       ` Pierre Neidhardt
  0 siblings, 0 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-12 14:13 UTC (permalink / raw)
  To: Julien Lepiller, guix-devel

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

Julien Lepiller <julien@lepiller.eu> writes:

> Because building this one will also rebuild the other two, re-read the sentence carefully :)
>
> llvm -> clang -> clang-toolchain

Oh! :D

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12  9:06 Reducing LLVM closure size Pierre Neidhardt
  2020-06-12 12:01 ` Julien Lepiller
@ 2020-06-13 12:28 ` Arun Isaac
  2020-06-13 15:34   ` Pierre Neidhardt
  2020-06-16  9:22 ` Ludovic Courtès
  2 siblings, 1 reply; 16+ messages in thread
From: Arun Isaac @ 2020-06-13 12:28 UTC (permalink / raw)
  To: Pierre Neidhardt, guix-devel

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]


> Since LLVM is all over the place, _multiple_ versions of LLVM inevitably
> end up in anyone's graph.

Is it possible to build a full system completely avoiding LLVM and only
using GCC?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-13 12:28 ` Arun Isaac
@ 2020-06-13 15:34   ` Pierre Neidhardt
  0 siblings, 0 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-13 15:34 UTC (permalink / raw)
  To: Arun Isaac, guix-devel

[-- Attachment #1: Type: text/plain, Size: 115 bytes --]

I believe many programs including Mesa explicitly depend on LLVM.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-12  9:06 Reducing LLVM closure size Pierre Neidhardt
  2020-06-12 12:01 ` Julien Lepiller
  2020-06-13 12:28 ` Arun Isaac
@ 2020-06-16  9:22 ` Ludovic Courtès
  2020-06-16  9:27   ` Pierre Neidhardt
  2 siblings, 1 reply; 16+ messages in thread
From: Ludovic Courtès @ 2020-06-16  9:22 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> For the first 2 links, click on
> "View the file list for ..." link at the bottom to display the file
> list.
>
> "bin" and "include" occupy some 35 MiB.  First thing we can do is split
>
> - either move the libs to a "lib" output,
> - or move the "bin" and "include" folder to a new output.
>
> The second approach has the benefit of being less disruptive for dependents.

I have a slight preference for a “lib” output since that’s more in line
with what we do for other packages.

> Now if we look at the PKGBUILD, there are some interesting compilation
> flags.  If we remove
>
>   "-DBUILD_SHARED_LIBS:BOOL=TRUE"
>
> and add
>
>   "-DLLVM_BUILD_LLVM_DYLIB=ON"
>   "-DLLVM_LINK_LLVM_DYLIB=ON"
>
> it will produce a single libLLVM-10.so library.  This reduces the "lib"
> folder size from 107 MiB to 90 MiB.

Nice!  I looked for something like this when I packaged
‘clang-tools-extra’ and didn’t find it.  This should go into the next
‘staging’ branch (or ‘core-updates’?).

> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
> package (and 210 MiB from its closure).

That’d be great.

An additional option would be to have a package with fewer backends by
default (currently all of them are enabled and that takes up quite some
space).  In particular, Mesa doesn’t depend to depend on an LLVM variant
with 15 backends when it’s only going to use one.

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-16  9:22 ` Ludovic Courtès
@ 2020-06-16  9:27   ` Pierre Neidhardt
  2020-06-16  9:45     ` Efraim Flashner
  2020-06-23  8:41     ` Pierre Neidhardt
  0 siblings, 2 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-16  9:27 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> - either move the libs to a "lib" output,
>> - or move the "bin" and "include" folder to a new output.
>>
>> The second approach has the benefit of being less disruptive for dependents.
>
> I have a slight preference for a “lib” output since that’s more in line
> with what we do for other packages.

OK.

> Nice!  I looked for something like this when I packaged
> ‘clang-tools-extra’ and didn’t find it.  This should go into the next
> ‘staging’ branch (or ‘core-updates’?).

I can send a patch for llvm-10, but I guess many llvm-dependents will
have to be updated accordingly.

I suppose that the input

--8<---------------cut here---------------start------------->8---
("llvm" ,llvm)
--8<---------------cut here---------------end--------------->8---

will need to be turned to

--8<---------------cut here---------------start------------->8---
("llvm" ,llvm "lib")
--8<---------------cut here---------------end--------------->8---

for most packages.  I have no experience with LLVM, so can someone
confirm that this is the right way to go?

>> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
>> package (and 210 MiB from its closure).
>
> That’d be great.

To clarify the ambiguous sentence I wrote above, we would save 52 MiB
from the closure size of LLVM.

> An additional option would be to have a package with fewer backends by
> default (currently all of them are enabled and that takes up quite some
> space).  In particular, Mesa doesn’t depend to depend on an LLVM variant
> with 15 backends when it’s only going to use one.

Are you suggesting an alternative or a tweak to add on top of my
suggestion?

Where would we store the different backends?  In different outputs?
On which backend does Mesa depend for instance?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-16  9:27   ` Pierre Neidhardt
@ 2020-06-16  9:45     ` Efraim Flashner
  2020-06-16 10:11       ` Pierre Neidhardt
  2020-07-07  8:49       ` Pierre Neidhardt
  2020-06-23  8:41     ` Pierre Neidhardt
  1 sibling, 2 replies; 16+ messages in thread
From: Efraim Flashner @ 2020-06-16  9:45 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Tue, Jun 16, 2020 at 11:27:45AM +0200, Pierre Neidhardt wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> >> - either move the libs to a "lib" output,
> >> - or move the "bin" and "include" folder to a new output.
> >>
> >> The second approach has the benefit of being less disruptive for dependents.
> >
> > I have a slight preference for a “lib” output since that’s more in line
> > with what we do for other packages.
> 
> OK.
> 

I see the include directory is about 20MB, can that be left in "out" or
is that needed in the "lib" output?

> > Nice!  I looked for something like this when I packaged
> > ‘clang-tools-extra’ and didn’t find it.  This should go into the next
> > ‘staging’ branch (or ‘core-updates’?).
> 
> I can send a patch for llvm-10, but I guess many llvm-dependents will
> have to be updated accordingly.
> 
> I suppose that the input
> 
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm)
> --8<---------------cut here---------------end--------------->8---
> 
> will need to be turned to
> 
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm "lib")
> --8<---------------cut here---------------end--------------->8---
> 
> for most packages.  I have no experience with LLVM, so can someone
> confirm that this is the right way to go?
> 
> >> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM
> >> package (and 210 MiB from its closure).
> >
> > That’d be great.
> 
> To clarify the ambiguous sentence I wrote above, we would save 52 MiB
> from the closure size of LLVM.
> 
> > An additional option would be to have a package with fewer backends by
> > default (currently all of them are enabled and that takes up quite some
> > space).  In particular, Mesa doesn’t depend to depend on an LLVM variant
> > with 15 backends when it’s only going to use one.
> 
> Are you suggesting an alternative or a tweak to add on top of my
> suggestion?
> 
> Where would we store the different backends?  In different outputs?
> On which backend does Mesa depend for instance?

I would assume llvmpipe

> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-16  9:45     ` Efraim Flashner
@ 2020-06-16 10:11       ` Pierre Neidhardt
  2020-07-07  8:49       ` Pierre Neidhardt
  1 sibling, 0 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-16 10:11 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

> I see the include directory is about 20MB, can that be left in "out" or
> is that needed in the "lib" output?

It can be left out, I mentioned it in my first email.

>> Where would we store the different backends?  In different outputs?
>> On which backend does Mesa depend for instance?
>
> I would assume llvmpipe

OK, thanks!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-16  9:27   ` Pierre Neidhardt
  2020-06-16  9:45     ` Efraim Flashner
@ 2020-06-23  8:41     ` Pierre Neidhardt
  2020-06-28 20:30       ` Ludovic Courtès
  1 sibling, 1 reply; 16+ messages in thread
From: Pierre Neidhardt @ 2020-06-23  8:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

Hi!

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Nice!  I looked for something like this when I packaged
>> ‘clang-tools-extra’ and didn’t find it.  This should go into the next
>> ‘staging’ branch (or ‘core-updates’?).
>
> I can send a patch for llvm-10, but I guess many llvm-dependents will
> have to be updated accordingly.
>
> I suppose that the input
>
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm)
> --8<---------------cut here---------------end--------------->8---
>
> will need to be turned to
>
> --8<---------------cut here---------------start------------->8---
> ("llvm" ,llvm "lib")
> --8<---------------cut here---------------end--------------->8---
>
> for most packages.  I have no experience with LLVM, so can someone
> confirm that this is the right way to go?

Friendly ping :)
Should I send a patch?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-23  8:41     ` Pierre Neidhardt
@ 2020-06-28 20:30       ` Ludovic Courtès
  2020-07-28 10:09         ` Pierre Neidhardt
  0 siblings, 1 reply; 16+ messages in thread
From: Ludovic Courtès @ 2020-06-28 20:30 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Nice!  I looked for something like this when I packaged
>>> ‘clang-tools-extra’ and didn’t find it.  This should go into the next
>>> ‘staging’ branch (or ‘core-updates’?).
>>
>> I can send a patch for llvm-10, but I guess many llvm-dependents will
>> have to be updated accordingly.
>>
>> I suppose that the input
>>
>> --8<---------------cut here---------------start------------->8---
>> ("llvm" ,llvm)
>> --8<---------------cut here---------------end--------------->8---
>>
>> will need to be turned to
>>
>> --8<---------------cut here---------------start------------->8---
>> ("llvm" ,llvm "lib")
>> --8<---------------cut here---------------end--------------->8---
>>
>> for most packages.  I have no experience with LLVM, so can someone
>> confirm that this is the right way to go?
>
> Friendly ping :)
> Should I send a patch?

Yes, please!

Ludo’.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-16  9:45     ` Efraim Flashner
  2020-06-16 10:11       ` Pierre Neidhardt
@ 2020-07-07  8:49       ` Pierre Neidhardt
  1 sibling, 0 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-07-07  8:49 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

>> Where would we store the different backends?  In different outputs?
>> On which backend does Mesa depend for instance?
>
> I would assume llvmpipe

Actually what is llvmpipe?  I cannot find it.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Reducing LLVM closure size
  2020-06-28 20:30       ` Ludovic Courtès
@ 2020-07-28 10:09         ` Pierre Neidhardt
  0 siblings, 0 replies; 16+ messages in thread
From: Pierre Neidhardt @ 2020-07-28 10:09 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Partially done:

42576@debbugs.gnu.org

It's not working at the moment because header files are still referenced
in the dependents .so.  Any idea how to work around this?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2020-07-28 10:09 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-12  9:06 Reducing LLVM closure size Pierre Neidhardt
2020-06-12 12:01 ` Julien Lepiller
2020-06-12 12:09   ` Oliver Propst
2020-06-12 13:19   ` Pierre Neidhardt
2020-06-12 13:34     ` Julien Lepiller
2020-06-12 14:13       ` Pierre Neidhardt
2020-06-13 12:28 ` Arun Isaac
2020-06-13 15:34   ` Pierre Neidhardt
2020-06-16  9:22 ` Ludovic Courtès
2020-06-16  9:27   ` Pierre Neidhardt
2020-06-16  9:45     ` Efraim Flashner
2020-06-16 10:11       ` Pierre Neidhardt
2020-07-07  8:49       ` Pierre Neidhardt
2020-06-23  8:41     ` Pierre Neidhardt
2020-06-28 20:30       ` Ludovic Courtès
2020-07-28 10:09         ` Pierre Neidhardt

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git