Re:Flat washers,factory
Hi We are Flat Washers Factory in China. Do you want to get flat washers from factory directly? Send me back for more information. Aaron Dongyue Industry Group Co.,Ltd mob whatsapp wechat skype:0086-18506351127 DIN125,9021,440 SAE /USS, ISO, JIS, BS, NFE, etc and Non-standard flat washers factory
Re: environment is too large for exec
On Wed, 4 Mar 2020, Andrey Repin wrote: > Greetings, Satish Balay! > > > I'm seeing the following error from cygwin: > > > "environment is too large for exec" > > > I can try reducing the env - however - is there an option in cygwin to > > increase the current 'max env'? > > As far as I recall, this is an OS limit. Ah so that can't be changed. Thanks for the info. > Most often this is caused by an overgrown %PATH% variable. Inspect it and > cleanup from stuff unused/unnecessary. There's many ways to make executables > visible without adding them to %PATH%. In this case - it was gitlab-runner setting up an env var with the commit message - this was long. Satish -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Has rename syntax changed?
Am 04.03.2020 um 04:52 schrieb L A Walsh: On 2020/03/03 15:45, Hans-Bernhard Bröker wrote: Am 04.03.2020 um 00:25 schrieb L A Walsh: On 2020/02/28 04:38, Fergus Daly wrote: I am almost certain that the command $ rename "anything" "AnyThing" *.ext would alter the string from lc to uc as shown, anywhere it occurred in any filename in *.ext in the current directory. isn't that they same as "mv anything.xxx Anything.xxx" ? No. For three reasons: *) it's .ext, not .xxx :-) *) it will find and replace 'anything' _anywhere_in_ the filename, not just in the basename. I'm confused about your terminology. The terminology is fine, but the statement isn't quite. That had better have read: >> it will find and replace 'anything' _anywhere_in_ the filename, not >> just if that's the entire basename. You said all of the filenames must match '*.ext'. No, I didn't. I said that rename will work on all files in the cwd matching *.ext. Files in the cwd not matching *.ext will be left alone. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: environment is too large for exec
Greetings, Satish Balay! > I'm seeing the following error from cygwin: > "environment is too large for exec" > I can try reducing the env - however - is there an option in cygwin to > increase the current 'max env'? As far as I recall, this is an OS limit. Most often this is caused by an overgrown %PATH% variable. Inspect it and cleanup from stuff unused/unnecessary. There's many ways to make executables visible without adding them to %PATH%. -- With best regards, Andrey Repin Wednesday, March 4, 2020 22:24:03 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ASLR revisited
Greetings, John Selbie! > For my open source project, I publish source code for Unix written in C++. > And as a convenience, I publish Win32 binaries compiled with Cygwin's g++ > build. I bundled the compiled EXE along with the dependent Cygwin DLLs > (cygcrypto, cyggcc, cycstdc++, cygwin1, and cygz.dll). > Someone rang me up today and said, "We're about to go live with your > pre-compiled binaries for Windows, but our compliance testing detected your > code isn't using ASLR (Address Space Layout Randomization). Can you fix?" > A quick internet search reveals that Cygwin has a compatibility issue with > ASRL. Process Explorer from sysinternals.com reveals that the process runs > without ASLR. As far as I recall, POSIX forking semantics are incompatible with ASLR. So, if my memory serves me well, the answer is "don't do that, your application will break badly." > Is there a workaround for allowing Cygwin code to have ASLR? I don't need > the fork() function. Build your application for native API. That's the only right answer. -- With best regards, Andrey Repin Wednesday, March 4, 2020 22:09:21 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Change in logical link behaviour
Greetings, Rainer Emrich! > Ok, so I can't rely on powershell here. Is there a recommended procedure > for what I try in a script? > Check if the current cygwin environment is able to create native symlinks. There's more than just Cygwin involved. 1. Target FS may not support symlinks. 2. User may not have necessary permission. If, for some reason, you DO actually required to create symlinks, go with winsymlinks:native, they are safer for use and relatively well supported in other tools. -- With best regards, Andrey Repin Wednesday, March 4, 2020 21:50:02 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cat /proc/partitions shows only devices, not partitions
Greetings, Hashim Aziz!
> This was an issue that I had previously in September of last year and sent
> the issue to this mailing list ("win-mounts no longer displays anything when
> doing "cat /proc/partitions") but the issue stopped occurring before I could
> get around to diagnosing it. This issue has now re-occurred and this time it
> seems permanent. When I run:
> $ cat /proc/partitions
> major minor #blocks name win-mounts
> 8 0 0 sda
> 816 0 sdb
> 832 0 sdc
> 848 0 sdd
> 864 0 sde
> 880 0 sdf
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 78150744 sda
8 1102400 sda1
8 2131072 sda2
8 3 77916160 sda3 C:\ C:\dev\sda1\
816 488386584 sdb
817 486615520 sdb1
832 488386584 sdc
833 488384512 sdc1
848 312571224 sdd
849 312568641 sdd1
864 0 sde
880 0 sdf
896 0 sdg
8 112 0 sdh
> ...I see nothing at all in the win-mounts column. This makes it impossible
> for me to see which Windows drive letter maps to which /dev/sdX entry.
This seems like a permissions issue.
> win-mounts column. I'm running Cygwin on Windows 7 (yes I'm aware it's EOL).
Same here. Win 7 Pro SP1.
--
With best regards,
Andrey Repin
Wednesday, March 4, 2020 22:00:31
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
environment is too large for exec
Hi, I'm seeing the following error from cygwin: "environment is too large for exec" I can try reducing the env - however - is there an option in cygwin to increase the current 'max env'? Please include me in cc: in replies. Thanks, Satish -- Note: In a prior run - I got the following [confusing] error. I'm assuming its the same issue. # n "bc_ctl.arg_max >= LINE_MAX" failed: file "/usr/src/findutils-4.6.0-1.x86_64/src/findutils-4.6.0/xargs/xargs.c", line 500, function: main # /home/glci2/builds/p34_q_s8/0/petsc/petsc/lib/petsc/bin/petscdiff: line 60: 42848 Donecat ex19_logviewmemory.tmp #42852 | grep MatFDColorSetUp #42856 | wc -w #42858 Aborted (core dumped) | xargs -I % sh -c "expr % \> 21" > ex19_logviewmemory.tmp.filter_tmp -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Brian Inglis writes:
> On 2020-03-03 15:02, Henry S. Thompson wrote:
>> cygcheck output attached, just in case...
>>
>> Per previous message, had to interrupt id, which was hanging, which
>> produced
>>
>> garbled output from "id" command - no uid= found
And yes, I inadvertently left out the 'cmd' line in the previous message.
> ...
> that can be affected by {HKLM,HKCU}/Software/Microsoft/Command Processor/
> registry entries e.g.:
>
> $ regtool list -v
> /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command\ Processor
> ...
> $ regtool list -v
> /proc/registry/HKEY_CURRENT_USER/SOFTWARE/Microsoft/Command\ Processor/
> Autorun (REG_EXPAND_SZ) = "@chcp 65001 >nul"
> ...
> runs chcp 65001 at cmd startup, but could also do much more and different.
Thanks, but mine are the same as yours, except _no_ Autorun in either
case, so I don't _think_ that's a possible source of the problem...
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 2020-03-03 15:02, Henry S. Thompson wrote:
> cygcheck output attached, just in case...
>
> Per previous message, had to interrupt id, which was hanging, which
> produced
>
> garbled output from "id" command - no uid= found
>
> while cygcheck carried on...
> and then hung with Process Explorer showing
>
> bash.exe
> bash.exe
> cygcheck.exe
>cmd.exe
> cygrunsrv.exe
As cygcheck is a Windows msvcrt.dll program, not a Cygwin cygwin1.dll program,
it uses Windows popen which runs commands under $COMSPEC rather than $SHELL, and
that can be affected by {HKLM,HKCU}/Software/Microsoft/Command Processor/
registry entries e.g.:
$ regtool list -v /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command\
Processor/
DefaultColor (REG_DWORD) = 0x (0)
EnableExtensions (REG_DWORD) = 0x0001 (1)
CompletionChar (REG_DWORD) = 0x0040 (64)
PathCompletionChar (REG_DWORD) = 0x0040 (64)
$ regtool list -v /proc/registry/HKEY_CURRENT_USER/SOFTWARE/Microsoft/Command\
Processor/
Autorun (REG_EXPAND_SZ) = "@chcp 65001 >nul"
CompletionChar (REG_DWORD) = 0x0009 (9)
DefaultColor (REG_DWORD) = 0x (0)
EnableExtensions (REG_DWORD) = 0x0001 (1)
PathCompletionChar (REG_DWORD) = 0x0009 (9)
runs chcp 65001 at cmd startup, but could also do much more and different.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] emacs 27.0.90-1 (TEST)
The following packages have been uploaded to the Cygwin distribution
as test releases:
* emacs-27.0.90-1
* emacs-common-27.0.90-1
* emacs-X11-27.0.90-1
* emacs-w32-27.0.90-1
* emacs-lucid-27.0.90-1
Emacs is a powerful, customizable, self-documenting, modeless text
editor. Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.
This is an update to an upstream pretest for the upcoming release of
emacs-27.1. Browse the NEWS file ('C-h n' within emacs) for changes
since the last release, although this is probably not yet complete.
CYGWIN NOTES
1. The emacs, emacs-w32, emacs-X11, and emacs-lucid packages each
provide an emacs binary. These are emacs-nox.exe, emacs-w32.exe,
emacs-X11.exe, and emacs-lucid.exe, respectively, in order of
increasing priority. The postinstall scripts create a symlink
/usr/bin/emacs that resolves to the highest-priority binary that
you have installed. Thus the command 'emacs' will start
emacs-lucid.exe if you've installed the emacs-lucid package;
otherwise, it will start emacs-X11.exe if you've installed
emacs-X11; otherwise, it will start emacs-w32.exe if you've
installed emacs-w32; otherwise, it will start emacs-nox.exe if
you've installed emacs. Similar remarks apply to emacsclient.
You only need to install one of these four packages, but you can
install more if you want. If you have installed more than one and
don't like the default resolution of /usr/bin/emacs, you can run
one of the /usr/bin/set-emacs-default-*.sh scripts to change it.
For example,
/usr/bin/set-emacs-default-w32.sh
will make /usr/bin/emacs resolve to /usr/bin/emacs-w32.exe,
regardless of which packages you've installed.
2. The emacs-common package contains the files that are needed by all
four of the binary packages mentioned above. It also contains the
elisp source files, which used to be in a separate (now obsolete)
emacs-el package.
3. Install emacs-X11 if you want to use the X11 GUI with the GTK+
toolkit. (This is the default toolkit.) You can then type
'emacs&' in an xterm window, and emacs-X11.exe will start in a new
window. If you prefer the Lucid toolkit, install emacs-lucid
instead.
4. Install emacs-w32 if you want to use the native Windows GUI instead
of X11.
5. If you use the Emacs MH-E library for email, consider installing
Cygwin's mailutils-mh package. To use it, put the line
(load "mailutils-mh")
in your site-start.el or ~/.emacs file.
6. If you have sshd running and want to be able to run emacs-X11 from
a remote machine, you need to enable X11 forwarding by adding the
following line to /etc/sshd_config:
X11Forwarding yes
You might also need to have the cygserver service running.
7. The script /usr/bin/make-emacs-shortcut can be used to create a
shortcut for starting emacs. See
/usr/share/doc/emacs/README.Cygwin for details.
Ken Brown
Cygwin's Emacs maintainer
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
emacs 27.0.90-1 (TEST)
The following packages have been uploaded to the Cygwin distribution
as test releases:
* emacs-27.0.90-1
* emacs-common-27.0.90-1
* emacs-X11-27.0.90-1
* emacs-w32-27.0.90-1
* emacs-lucid-27.0.90-1
Emacs is a powerful, customizable, self-documenting, modeless text
editor. Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.
This is an update to an upstream pretest for the upcoming release of
emacs-27.1. Browse the NEWS file ('C-h n' within emacs) for changes
since the last release, although this is probably not yet complete.
CYGWIN NOTES
1. The emacs, emacs-w32, emacs-X11, and emacs-lucid packages each
provide an emacs binary. These are emacs-nox.exe, emacs-w32.exe,
emacs-X11.exe, and emacs-lucid.exe, respectively, in order of
increasing priority. The postinstall scripts create a symlink
/usr/bin/emacs that resolves to the highest-priority binary that
you have installed. Thus the command 'emacs' will start
emacs-lucid.exe if you've installed the emacs-lucid package;
otherwise, it will start emacs-X11.exe if you've installed
emacs-X11; otherwise, it will start emacs-w32.exe if you've
installed emacs-w32; otherwise, it will start emacs-nox.exe if
you've installed emacs. Similar remarks apply to emacsclient.
You only need to install one of these four packages, but you can
install more if you want. If you have installed more than one and
don't like the default resolution of /usr/bin/emacs, you can run
one of the /usr/bin/set-emacs-default-*.sh scripts to change it.
For example,
/usr/bin/set-emacs-default-w32.sh
will make /usr/bin/emacs resolve to /usr/bin/emacs-w32.exe,
regardless of which packages you've installed.
2. The emacs-common package contains the files that are needed by all
four of the binary packages mentioned above. It also contains the
elisp source files, which used to be in a separate (now obsolete)
emacs-el package.
3. Install emacs-X11 if you want to use the X11 GUI with the GTK+
toolkit. (This is the default toolkit.) You can then type
'emacs&' in an xterm window, and emacs-X11.exe will start in a new
window. If you prefer the Lucid toolkit, install emacs-lucid
instead.
4. Install emacs-w32 if you want to use the native Windows GUI instead
of X11.
5. If you use the Emacs MH-E library for email, consider installing
Cygwin's mailutils-mh package. To use it, put the line
(load "mailutils-mh")
in your site-start.el or ~/.emacs file.
6. If you have sshd running and want to be able to run emacs-X11 from
a remote machine, you need to enable X11 forwarding by adding the
following line to /etc/sshd_config:
X11Forwarding yes
You might also need to have the cygserver service running.
7. The script /usr/bin/make-emacs-shortcut can be used to create a
shortcut for starting emacs. See
/usr/share/doc/emacs/README.Cygwin for details.
Ken Brown
Cygwin's Emacs maintainer
Re: Emacs gud not working on new installation
On Wed, Mar 4, 2020 at 9:58 AM Ken Brown wrote: > On 3/4/2020 9:44 AM, William M. (Mike) Miller wrote: > > I installed Cygwin on a new computer last weekend. On my previous > computer, > > I used gud with gdb in emacs (M-x gdb) for debugging. However, on the new > > computer it is not working. I suspect that gdb is producing output that > is > > not formatted correctly for gud to parse. [...snip...] > > I don't know whether this is an emacs problem or a Cygwin problem. Here > are two things you can try: > > 1. Roll back the cygwin package to 3.0.7 to see if that fixes the > problem. If so, the problem is likely related to the pty changes in > cygwin-3.1.x. > This worked. Thanks for the tip! -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup: How to automate source download for packages already installed?
On Wed, Mar 4, 2020 at 6:32 AM Jon Turney wrote: > If a package is listed for both -x and -P, it is reinstalled, so while > not ideal, you might be able to achieve something like what you want > with 'setup -I -x "package1,package2,package3" -P > "package1,package2,package3"' This does what I need. Thank you! > An option which explicitly just installs the source for a specified > package might be useful. Agreed. Perhaps this could get added to a new iteration of the setup tool. But combining -I, -x, and -P are a useful workaround. Thanks! Bill -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs gud not working on new installation
On 3/4/2020 9:44 AM, William M. (Mike) Miller wrote: I installed Cygwin on a new computer last weekend. On my previous computer, I used gud with gdb in emacs (M-x gdb) for debugging. However, on the new computer it is not working. I suspect that gdb is producing output that is not formatted correctly for gud to parse. When I start gud in emacs on the new computer, I get the usual 6-pane configuration, and gdb puts out its usual configuration and start-up information. When I type the "run" command, however, the program being debugged starts and runs, the command pane correctly displays the usual "Starting program" messaged, but the "[New thread...", etc. messages and any further gdb output (breakpoint messages, output of "info", etc.) do not. The program input/output pane updates, but none of the others do. I can type commands that are correctly passed through to gdb, but no gdb output ever appears in the command pane. I also tried just the plain "M-x gud-gdb" interface, and that may give a hint as to what is going on. I did get the gdb output, but with only newlines, no carriage returns, in the command pane. That is, each successive line of output from gdb began one character to the right of the last character of the previous line instead of beginning in column 0, as it did on the old computer. Any suggestions for how to diagnose or fix the problem would be most appreciated. I don't know whether this is an emacs problem or a Cygwin problem. Here are two things you can try: 1. Roll back the cygwin package to 3.0.7 to see if that fixes the problem. If so, the problem is likely related to the pty changes in cygwin-3.1.x. 2. Try updating emacs to the test release for the upcoming emacs-27, which I will be uploading shortly. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Emacs gud not working on new installation
I installed Cygwin on a new computer last weekend. On my previous computer, I used gud with gdb in emacs (M-x gdb) for debugging. However, on the new computer it is not working. I suspect that gdb is producing output that is not formatted correctly for gud to parse. When I start gud in emacs on the new computer, I get the usual 6-pane configuration, and gdb puts out its usual configuration and start-up information. When I type the "run" command, however, the program being debugged starts and runs, the command pane correctly displays the usual "Starting program" messaged, but the "[New thread...", etc. messages and any further gdb output (breakpoint messages, output of "info", etc.) do not. The program input/output pane updates, but none of the others do. I can type commands that are correctly passed through to gdb, but no gdb output ever appears in the command pane. I also tried just the plain "M-x gud-gdb" interface, and that may give a hint as to what is going on. I did get the gdb output, but with only newlines, no carriage returns, in the command pane. That is, each successive line of output from gdb began one character to the right of the last character of the previous line instead of beginning in column 0, as it did on the old computer. Any suggestions for how to diagnose or fix the problem would be most appreciated. -- William M. (Mike) Miller | Edison Design Group william.m.mil...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Fwd: sourceware.org migration notice
Assuming this migration goes ahead as planned this weekend: * I'll stop package upload processing sometime on Friday * An announcement will be made when package upload processing is restored. * Cygwin setup should continue to function (if it can't contact cygwin.com to fetch the mirror list, it should use a cached mirror list, and all package downloads are from a mirror) Forwarded Message Subject: sourceware.org migration notice Date: 26 Feb 2020 23:13:41 - From: r...@sourceware.org Hi - As a developer/accountholder on sourceware.org / gcc.gnu.org / cygwin.com, this email is to notify you about an upcoming service disruption involved in migrating its services to a new server & new datacenter. This is currently scheduled to take place the weekend of March 7/8, 2020. For more details, please keep an eye on the following web page, https://sourceware.org/sourceware-wiki/MigrationStatus , and the #overseers IRC channel on freenode. (If you are no longer involved in any of the projects hosted here, please let us know so we can mark your account as an "emeritus" member and we don't bother you again.) - FChE
Re: Setup: How to automate source download for packages already installed?
On 02/03/2020 18:06, Bill Stewart wrote: I would like to reinstall a set of packages and automatically install the source for only those packages. The packages are currently installed, and I am using a Setup command line like this: -I -P "package1,package2,package3" The description in --help for -I states "Automatically install source for every package installed". It would seem that, in this case, since the named packages are already installed and up-to-date, the -I option does nothing. Is my analysis correct? This is correct. If so, what is the way to automate source download for a set of packages that are already installed? If a package is listed for both -x and -P, it is reinstalled, so while not ideal, you might be able to achieve something like what you want with 'setup -I -x "package1,package2,package3" -P "package1,package2,package3"' An option which explicitly just installs the source for a specified package might be useful. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failing build when using binutils 2.34-1 on Cygwin 32/64-bit
On 3/4/20 8:59 AM, Joachim Metz wrote: > I maintain numerous projects, as part of that I've set up CI tests that use > current Cygwin 32-bit and 64-bit. Recently I've noticed that builds were > failing with errors like: > > https://ci.appveyor.com/project/libyal/libfwsi/build/job/7b822r4j4ghfs2m5#L953 > > /usr/lib/gcc/i686-pc-cygwin/9.2.0/../../../../i686-pc-cygwin/bin/ld: > fwsi_test_error.o: in function `fwsi_test_error_sprint': > /home/appveyor/libfwsi/tests/fwsi_test_error.c:72: undefined reference to > `_imp__libfwsi_error_sprint' > > https://ci.appveyor.com/project/libyal/libfwsi/build/job/3qnu5pk3lm4u12pe#L960 > > /home/appveyor/libfwsi/tests/fwsi_test_error.c:72: undefined reference to > `__imp_libfwsi_error_sprint' > /home/appveyor/libfwsi/tests/fwsi_test_error.c:72:(.text.startup+0x24): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol > `__imp_libfwsi_error_sprint' > > Since I did not make significant changes to the project sources I started > analyzing the build environment. I was able to reproduce the issues > with binutils 2.34-1 on Cygwin 64-bit on a separate Windows 10 > installation. > > When I reverted to binutils 2.31-1 the build issues do NOT surface. I > suspect a change or issue with binutils 2.34-1 is causing the build issues. > Happy to provide additional details / help troubleshooting where possible. > > Kind regards, > Joachim > Can you compare the objects where that symbol is supposed to be defined and the objects where it is supposed to be referenced between the 2 binutils versions? Can you make a minimalist test case? Might be a good idea to file a ticket with binutils too. signature.asc Description: OpenPGP digital signature
Failing build when using binutils 2.34-1 on Cygwin 32/64-bit
I maintain numerous projects, as part of that I've set up CI tests that use current Cygwin 32-bit and 64-bit. Recently I've noticed that builds were failing with errors like: https://ci.appveyor.com/project/libyal/libfwsi/build/job/7b822r4j4ghfs2m5#L953 /usr/lib/gcc/i686-pc-cygwin/9.2.0/../../../../i686-pc-cygwin/bin/ld: fwsi_test_error.o: in function `fwsi_test_error_sprint': /home/appveyor/libfwsi/tests/fwsi_test_error.c:72: undefined reference to `_imp__libfwsi_error_sprint' https://ci.appveyor.com/project/libyal/libfwsi/build/job/3qnu5pk3lm4u12pe#L960 /home/appveyor/libfwsi/tests/fwsi_test_error.c:72: undefined reference to `__imp_libfwsi_error_sprint' /home/appveyor/libfwsi/tests/fwsi_test_error.c:72:(.text.startup+0x24): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_libfwsi_error_sprint' Since I did not make significant changes to the project sources I started analyzing the build environment. I was able to reproduce the issues with binutils 2.34-1 on Cygwin 64-bit on a separate Windows 10 installation. When I reverted to binutils 2.31-1 the build issues do NOT surface. I suspect a change or issue with binutils 2.34-1 is causing the build issues. Happy to provide additional details / help troubleshooting where possible. Kind regards, Joachim P.S. I tried searching for duplicate issues on https://sourceware.org/cgi-bin/search.cgi?form=extended= unfortunately it returns a lot of results and starts with the oldest results first. Small request for the future, consider adding an option to return results in reverse order. Tracking this for the libyal projects in https://github.com/libyal/libyal/issues/83 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
