Hello, sorry for the delay to your message. Unfortunately, you are right, the debuginfo package is not created correctly after my patch. So, the correction that I had sent was not good.
To explain better the problem, I created a tiny example that you can use.
Attached to this email there is a "test.zip" file.
The "test.zip" file contains these files:
- test.cygport
- test-1.2.3.zip
And "test-1.2.3.zip" just contains the meson.build file.
The objective of the test is to show that the process hangs when using
a cross compiler.
In this case, I did it for x86_64-w64-mingw32.
This test requires that you have installed mingw64-x86_64-glib into your tree.
As you know, you can verify that it exists by typing:
$ x86_64-w64-mingw32-pkg-config --modversion glib-2.0
2.54.3
So, after unpacking the "test.zip" file, type first:
cygport test.cygport prep
and it will print this on the console:
>>> Preparing mingw64-x86_64-test_cygport-1.2.3-1.noarch
>>> Unpacking source test-1.2.3.zip
>>> Preparing working source directory
Now, type this:
cygport test.cygport compile
And you will get this error:
Build type: cross build
Project name: test-cygport
Project version: 1.2.3
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: x86_64
Target machine cpu family: x86_64
Target machine cpu: x86_64
Found pkg-config: YES (/usr/bin/x86_64-w64-mingw32-pkg-config) 2.3.0
Found CMake: NO
Run-time dependency glib-2.0 found: NO (tried pkgconfig)
meson.build:10:11: ERROR: Dependency "glib-2.0" not found, tried pkgconfig
A full log can be found at
/home/carlo/packages/lv2.src/zix/test/mingw64-x86_64-test_cygport-1.2.3-1.noarch/src/test-1.2.3/x86_64-w64-mingw32/meson-logs/meson-log.txt
*** ERROR: meson failed
The error does not happen if we are compiling without using a cross compiler.
The same package build for CYGWIN instead of MinGW-w64 works fine.
I don't know why it happens.
The only way to bypass this issue was to run meson outside ${S} but I
cannot explain the reason.
I hope that it will help to find the cause of the problem.
Sincerely,
Carlo Bramini.
Il giorno ven 28 feb 2025 alle ore 17:22 Jon Turney
<jon.tur...@dronecode.org.uk> ha scritto:
>
> On 21/02/2025 10:40, Carlo B. via Cygwin-apps wrote:
> > Hello,
> > I'm doing packages for CYGWIN, with updated or missing libraries that
> > you can find here:
> >
> > https://github.com/carlo-bramini/packages-cygwin
> >
> > While doing this task, I got troubles when using Cygport with Meson.
> > If I create packages for CYGWIN, x86_64 or i686, I works fine.
> > But if I create packages by using cross compilers, in other words
> > NOARCH stuff, it doesn't work.
> > To be more precise, existing libraries and tools into the sysroot are not
> > found.
>
> Thanks.
>
> Hmm... I don't quite understand why this change has the effect of
> resolving this problem.
>
> Can you explain?
>
> > This is an example output when building librubberband with MinGW cross
> > compilers:
> >
> > Run-time dependency fftw3 found: NO (tried pkgconfig and cmake)
> > Run-time dependency sleef found: NO (tried pkgconfig and cmake)
> > Run-time dependency sleefdft found: NO (tried pkgconfig and cmake)
> > Run-time dependency samplerate found: NO (tried pkgconfig and cmake)
> > Run-time dependency speexdsp found: NO (tried pkgconfig and cmake)
> >
> > I did a correction to Meson.cygclass and now it works like this:
> >
> > Run-time dependency fftw3 found: YES 3.3.5
> > Run-time dependency sleef found: NO (tried pkgconfig and cmake)
> > Run-time dependency sleefdft found: NO (tried pkgconfig and cmake)
> > Run-time dependency samplerate found: YES 0.1.8
> > Run-time dependency speexdsp found: YES 1.2rc3
> >
> > After applying attached patch, the object files will be generated
> > inside ${B} rather than into a subdir of ${S}.
> > I have found no other way to make it working.
> > But afterall, ${B} exists for this purpose and I don't see a good
> > reason because ${S} should be polluted with object files.
>
> Yeah, it would be nice if meson worked in the same way as the other
> build systems.
>
> Unfortunately, this wasn't written by me, and I'd need to go digging
> through history to discover all the details.
>
> If I recall correctly, it's related to how we use the gcc options
> -fdebug-prefix-map or -ffile-prefix-map.
>
> (See the thread starting at [1] for a bit of discussion around these
> options)
>
> Those work (or at least, worked) by string prefix substitution, rather
> than path manipulation, and the forms of the paths passed to the
> compiler by (the ninja file generated by) meson aren't amenable the same
> simple manipulations relative to ${B} as other build systems (e.g.
> autotools).
>
>
> So I guess the first question to ask is if you're still getting correct
> debuginfo package generation with this patch?
>
>
> [1] https://cygwin.com/pipermail/cygwin-apps/2023-September/043185.html
<<attachment: test.zip>>
