= R_X86_64_PC64)
+#endif
#if defined (R_X86_64_DTPOFF32)
| (type == R_X86_64_DTPOFF64)
#endif
Thanks for the report.
I've added the little object file
to the regression test base.
Regards,
David Anderson
On Mon, Sep 2, 2019 at 4:13 PM Michael Biebl wrote:
>
> Am 03.09.19 um 01:07 schrieb David Anderson:
> > If possible, could this fix be released as a Buster update as well?
> > This bug prevents the use of networkd to set up Wireguard VPN servers
> > on Buster, and it'
If possible, could this fix be released as a Buster update as well?
This bug prevents the use of networkd to set up Wireguard VPN servers
on Buster, and it's hard to workaround without resorting to racey
shell scripts.
On 12/24/18 6:23 AM, Fabian Wolff wrote:
> Control: tags -1 + upstream
>
> Dear Tj,
>
> thanks for reporting this problem. I am hereby forwarding it to dwarfdump's
> upstream developer, David Anderson.
>
> David, could you have a look at this? Thank you!
>
&g
On 03/27/2018 09:34 PM, Helmut Grohne wrote:
> I suggest that resend your previous mail after carefully checking each
> of the words "build", "host", and "target" against their definitions
> (and telling which definition you used unless you use GNU terminology).
Ah. Thanks. That I can do.
And I wi
On 03/26/2018 09:26 PM, Helmut Grohne wrote:
> Cool. Before we continue, could you do a brief terminology check? Both
> autotols and Debian (dpkg) use GNU terminology[1] for build/host/target.
> This notably differs from mozilla terminology and tends to cause
> confusion. Please stick with GNU term
tically in
the arm tree.
cd libdwarf
./configure --host=--host=arm-linux-gnueabihf --disable-libz
make
cd ../dwarfdump
./configure --host=--host=arm-linux-gnueabihf --disable-libz
make
David Anderson
--
...the Linux philosophy is "laugh in the face of danger".
Oops. Wrong one. "D
rt, cannot
find anything on the web but words admitting it is
a problem.
Pushed this stuff to sourceforge
so it at least actually builds libdwarf
and gets dwarfdump objects built
though the final link fails on the -lz
issue.
Any suggestions to detect -lz in the target
libraries?
David Anderson
On 03/21/2018 11:46 AM, Helmut Grohne wrote:
> If you ask me, don't embed. Just don't do it. Also don't ship compiled
> code (e.g. generated configure scripts). But that's just me.
I will skip embedding. And stick with AC_PATH_PROG.
To do cross-build of just libdwarf, I am pondering the idea of
s build (e.g. --host=arm-linux-gnueabihf).
I'm running Xubuntu so that should work.
I had no idea it was that easy.
Finishing up some DWARF5 work in libdwarf now, but over the next few days I
hope to work on the cross issue.
The diff you attached is good.
Thanks.
David Anderson
--
Don
do is
quite a surprise to me. Even shocking.
I don't think I have any objection to doing that if
that approach is widely accepted.
David Anderson
[And what about libelf? Include it too because
it is not available automatically to all?
Where to stop embedding?]
--
Don't worry about peo
Package: mongrel
Version: 1.1.1-1
Severity: grave
Justification: renders package unusable
After installing Mongrel, attempting to start it from Rails results in the
following traceback:
Exiting
/usr/lib/ruby/1.8/http11.so: /usr/lib/ruby/1.8/http11.so: invalid ELF header -
/usr/lib/ruby/1.8/http1
Package: wnpp
Severity: wishlist
Owner: David Anderson <[EMAIL PROTECTED]>
* Package name: python-pynxt
Version : 0.0.1
Upstream Author : David Anderson <[EMAIL PROTECTED]>
* URL : https://ssl.natulte.net/nxos/devel
* License : GPLv2
Programming
13 matches
Mail list logo
