Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am trying to use wget via Cygwin to fetch some content from a https website. Unfortunately when I try to connect I get the following error:
#wget https://www.mysite.com/mycontent
Connecting to XXXXXXXX... connected.
GnuTLS: A TLS fatal alert has been received.
Unable to establish SSL connection.
The certificate is a VeriSign Class 3 and is not expired. I have tried using options --no-check-certificate, --secure-protocol=SSLv2, --secure-protocol=SSLv3, etc which doesn't work but gives a slightly different error:
$ wget --secure-protocol=SSLv3 --no-check-certificate https://www.mysite.com/mycontent
Connecting to XXXXXX... connected.
GnuTLS: GnuTLS internal error.
Unable to establish SSL connection.
I also tried exporting the DER certificate from Internet Explorer on my PC and then passing that certificate to wget which also failed:
$ wget --certificate-type=DER --certificate=mysite.cer https://www.mysite.com/mycontent
Connecting to XXXXX... connected.
GnuTLS: A TLS fatal alert has been received.
Unable to establish SSL connection.
Is there something I'm missing? Can anyone point me in the direction of what I have to do to make this work?
Sorry but I had to redact the real server info for employer confidentiality reasons.
Here is my wget/cygwin configuration information:
$ wget --version
GNU Wget 1.13.4 built on cygwin.
+digest +https +ipv6 +iri +large-file +nls -ntlm +opie +ssl/gnutls
Wgetrc:
/etc/wgetrc (system)
Locale: /usr/share/locale
Compile: gcc-4 -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
-DLOCALEDIR="/usr/share/locale" -I.
-I/usr/src/wget-1.13.4-1/src/wget-1.13.4/src -I../lib
-I/usr/src/wget-1.13.4-1/src/wget-1.13.4/lib -g -O2 -pipe
Link: gcc-4 -g -O2 -pipe -liconv -lintl /usr/lib/libgnutls.dll.a
/usr/lib/libtasn1.dll.a /usr/lib/libz.dll.a
/usr/lib/libgcrypt.dll.a /usr/lib/libgpg-error.dll.a
/usr/lib/libintl.dll.a -L/usr/lib/ncursesw /usr/lib/libiconv.dll.a
-lgcrypt -lgpg-error -lz -lidn ftp-opie.o gnutls.o ../lib/libgnu.a
I've seen this happen when trying to wget something from an IIS box. There's an IIS bug that incorrectly processes SSL requests. Browsers ignore it, wget doesn't.
If I recall correctly (it's been years), there's a wget setting that tells it to ignore SSL cert errors... Maybe it's the --sslcheckcert option. Try using --sslcheckcert=0.
Related
I am trying to build some software for AmigaDOS 3.x on a ubuntu 16.04 host system, but at link time I get this error:
/opt/m68k-amigaos/m68k-amigaos/bin/ld: cannot open crt0.o: No such file or directory
The process of building from .c to .o works fine and with no errors. Its only the link stage that displays any error. The link command I am using is:
sst: $(OFILES)
m68k-amigaos-gcc -o sst $(OFILES) -lm
Any ideas?
The question was answered here:
https://github.com/adtools/amigaos-cross-toolchain/issues/12
I will copy/paste it here, in case the original post on Github became unavailable:
You need to use -noixemul switch during linking stage, otherwise the toolchain will try to use ixemul startup routine which is not available.
$ m68k-amigaos-gcc -noixemul hello.c -o hello
I’m trying to run the make_torrent example code provide over here.
I’m have compiled and installed libtorrent based on what written over here
Here how I have complied and linked the make_torrent.cc file.
g++ -g -Wall make_torrent.cc -ltorrent-rasterbar -lboost_system -o make_torrent
Upon running the make_torrent sample code I see this
usage: make_torrent FILE [OPTIONS]
Generates a torrent file from the specified file
or directory and writes it to standard out
OPTIONS:
-m file generate a merkle hash tree torrent.
merkle torrents require client support
the resulting full merkle tree is written to
the specified file
-w url adds a web seed to the torrent with
the specified url
-t url adds the specified tracker to the
torrent. For multiple trackers, specify more
-t options
-c comment sets the comment to the specified string
-C creator sets the created-by field to the specified string
-p bytes enables padding files. Files larger
than bytes will be piece-aligned
-s bytes specifies a piece size for the torrent
This has to be a multiple of 16 kiB
-l Don't follow symlinks, instead encode them as
links in the torrent file
-o file specifies the output filename of the torrent file
If this is not specified, the torrent file is
printed to the standard out, except on windows
where the filename defaults to a.torrent
-r file add root certificate to the torrent, to verify
the HTTPS tracker
-S info-hash add a similar torrent by info-hash. The similar
torrent is expected to share some files with this one
-L collection add a collection name to this torrent. Other torrents
in the same collection is expected to share files
with this one.
-M make the torrent compatible with mutable torrents
this means aligning large files and pad them in order
for piece hashes to uniquely indentify a file without
overlap
dyld: lazy symbol binding failed: Symbol not found: _ERR_remove_thread_state
Referenced from: /usr/local/lib/libtorrent-rasterbar.9.dylib
Expected in: flat namespace
dyld: Symbol not found: _ERR_remove_thread_state
Referenced from: /usr/local/lib/libtorrent-rasterbar.9.dylib
Expected in: flat namespace
I know I have to provide the relevant argument to make torrent but I’m not sure why libtorrent is complaining about the linker
g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Any clue?
This is caused by not linking to openssl correctly. I'm assuming you're on OSX, which has an old version of openssl in the default install path.
I would suggest installing openssl with brew install openssl. Note that this requires you have homebrew installed.
After doing this, do brew info openssl and look lines telling you what to add to your LDFLAGS and CPPFLAGS. In my case:
For compilers to find this software you may need to set:
LDFLAGS: -L/usr/local/opt/openssl/lib
CPPFLAGS: -I/usr/local/opt/openssl/include
For pkg-config to find this software you may need to set:
PKG_CONFIG_PATH: /usr/local/opt/openssl/lib/pkgconfig
So in my case, I would then compile with:
g++ -g -Wall -L/usr/local/opt/openssl/lib -I/usr/local/opt/openssl/include make_torrent.cc -ltorrent-rasterbar -lboost_system -o make_torrent
If this does not work, I would also make sure that you include these flags when compiling libtorrent.
I'm trying to build fastText (Facebook's library for learning of word representations and sentence classification) and have tried followed the instructions on their Github page:
$ git clone git#github.com:facebookresearch/fastText.git
$ cd fastText
$ make
I installed GnuWin32 and added to the path in order to use the make function. I'm on Windows 10.
However I get the following error:
$ make
c++ -pthread -O3 -funroll-loops -std=c++0x -c src/args.cc
process_begin: CreateProcess(NULL, c++ -pthread -O3 -funroll-loops -std=c++0x -c src/args.cc, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [args.o] Error 2
Anyone has an idea on how to fix this? Thanks!
After posting this question Facebook clarified that FastText only builds on Mac OS and Linux distributions. See https://github.com/facebookresearch/fastText
I encountered similar errors when attempting to build fastText on Windows using MinGW tools. I went instead to use Visual C++ 2015 to build fastText and it worked fine after a few tweaks. I submitted a Pull Request for this change https://github.com/facebookresearch/fastText/pull/39
I also maintain a binary build of fastText for Windows. You can find it at http://cs.mcgill.ca/~mxia3/FastText-for-Windows/
FastText’s authors do not currently support building and running on Windows. There were attempts to run with Bash for Windows and MinGW. This unofficial build is compiled with Visual C++ 2015 to run natively on Windows
I'm getting the following error when I try to execute my make file:
clang: error: cannot specify -o when generating multiple output files
The issue occurred when I upgraded to Mac OSX Mavericks (Xcode 5.0.1). I have spent days trying to figure this problem out on the forums, and I'm just very lost. After deleting a previous XCode version, I reinstalled a clean one (from the Mac App Store). When I ran the following:
sudo port install gcc49
It froze trying to build libgcc-devel.
Any help as I'm desperate, working on dissertation work.
(Answered in the comments. See Question with no answers, but issue solved in the comments (or extended in chat) )
When the OP wrote:
readPVCData: readPVCData.o readfunc.o readlib.h
gcc -o readPVCData readPVCData.o readfunc.o readlib.h -lm -lsndfile
readPVCData.o: readPVCData.c readlib.h
gcc -c readPVCData.c
readfunc.o: readfunc.c readlib.h
gcc -c readfunc.c
#Kevin wrote:
Pretty sure your problem is the readlib.h in gcc -o readPVCData readPVCData.o readfunc.o readlib.h -lm -lsndfile. Take it out.
I am attempting to use GDB to debug a Stellaris LM3S8962 Evaluation board using OpenOCD and the GNU ARM toolchain (installed with MacPorts), whenever I set the remote target in GDB it always returns "Malfomred response to offset query, qOffsets". Any ideas on what could be going wrong? Is there anything that I am missing?
[bcochran#narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
>
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets
Here is the openocd output... as soon as the malformed response comes across openocd drops the telnet connection...
[bcochran#narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection
Here are the version outputs of my arm-none-eabi-* toolchain...
[bcochran#narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)
[bcochran#narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
I am able to compile using the toolchain, and flash the resultant .bin file using OpenOCD. I have been unable to find a solution to the "malformed response" issue just by searching the web.
Thanks in advance for any advice or assistance!
UPDATES
Thanks to answers from #turbo-j and #guy-sirton, I was able to progress a bit further... The most helpful thus far was that I was indeed using the wrong port (4444 instead of 3333) but now I am getting the following whether I add -c "init" -c "halt" -c "reset halt" to my openocd command string or not:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long: 0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001
(this is right after the qOffsets req/resp, which now passes)
On the OpenOCD side:
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection
With sometimes a undefined debug reason 6 - target needs reset on the OpenOCD console...not sure what is going on now but it seems closer to functioning
UPDATES 2
It seems if I do not load the file 'main.axf' or 'main.o' I do not run into the Remote 'g' packet reply is too long but I get no symbols... I've noticed other websites deal primarily with the .elf extension. What is the difference? I'm using the "Hello World" example from StellarisWare which it generates main.axf, main.bin (flash writes and runs fine), main.d, main.o from the make command. Something odd about my Makefile?
Here is a patch like what #athquad mentioned. See his answer for more information. Thanks to him for efficiently pointing me at the right spot, and great shame indeed for offering a patch without providing it. :-P
http://pastebin.com/rdFF2eZd
Patch was made against openocd commit 631b80fd0835055bb385314f569f589b99d7441d
To use: (./configure options depend on jtag hardware)
git clone git://git.code.sf.net/p/openocd/code openocd
cd openocd
patch -p1 < /path/to/patch/file
./bootstrap
./configure --enable-maintainer-mode --enable-ft2232_libftdi
nice make && sudo make install
You used the wrong port. Use target remote localhost 3333 for the GDB-to-OpenOCD connection. The port 4444 is intended for human interaction via a terminal and can be used in addition to a GDB connection.
If you don't want to compile OpenOCD, as tacos' & atquad's answer, you can use an older release of the GNU ARM tool chain (7.2.5 is fine for example).
(0.4.0 and 0.5.0 windows precompiled are both giving this problem).
I have just encountered the same "'g' packet reply is too long" bug and traced it to its cause.
It seems that for a very long time GNU ARM tools have used an ARM model with 9 obsolete floating point registers. OpenOCD is wise to this and in response to GDB's register request supplies dummy values. However, recent eabi toolchains including GDB have come up to date and so your GDB no longer expects these registers - hence the message.
In the OpenOCD source I have patched armv7m_get_gdb_reg_list() in armv7m.c to make this work, but my patch isn't smart enough to know which GDB version is being used - it simply uses an #ifdef switch - so it would need a bit more work to integrate with the OpenOCD source code.
A patch could be available to anyone who wants.
I do a lot of remote debugging on ARM but with a different processor, OS, and toolchain :-) Nevertheless, here are some thoughts.
This suggestion:
openocd -f openocd.cfg -c "init" -c "halt" -c "reset halt"
Comes from here:
http://michaldemin.wordpress.com/2010/02/22/part-2-debugging-with-gdb-and-openocd/
Otherwise:
A mismatch in the remote gdb protocol between the remote and your gdb. You can try going to a different version of the toolchain. Google and find what works for others.
A communication issue. Try lower baud rate? Make sure the serial port parameters are sound.